Enhancement: Derive main easing files (including minified) from ESM source, with main ones assuming global jQuery
Enhancement: Add module, exports, browser, and type for ESM usage by bundlers or Node
Enhancement: Have CommonJS API require passing in jquery instance (passing in alone not sufficient)
Docs/Demo: Add Node CJS demo; give more on usage
Linting: More consistent styling
Refactoring: Switch to ES6 Modules in source
Refactoring: More ES6 in source
npm: Update jquery dep.; remove uglify-js (using Terser with Rollup)
A couple notes:
If you are open to it, I can move the jquery.easing.js and jquery.easing.min.js to a new dist folder, as that should make things a bit cleaner, though it would increase breakage as the path would change.
Since jQuery doesn't yet fully support ESM (e.g., see https://github.com/jquery/jquery/issues/4592 ), using import statements against jQuery in source would need our adding Rollup's commonjs plugin, and it would have the disadvantage of baking in a specific version of jQuery, adding to bundle size (unless we kept the import statement as an import statement, but then users would have to do their own bundling based on our bundle which isn't very convenient). So, currently, even one of the ESM source files relies on a jQuery global, though there is also another source file addJQueryEasing.js (in source at src/addJQueryEasing.mjs) which allows one to pass in one's own jQuery instance if that is desired. jQuery's current lack of proper ESM export is another reason I didn't bother with a native Node ESM demo, though I tentatively added such support in package.json (by the type and exports fields).
I changed the API for CJS to require passing in a jQuery instance. This is because one really must have some DOM built to use in Node, e.g., with jsdom to get things working properly (I added a demo that executes without error, but as it is in Node, there is of course no visual effect). Note that CJS support had been broken until recently anyways, so I don't think this necessitates a breaking change (nor, as a result, should I think the addition of exports be so, even though it normally would be a breaking change since it prevents Node access to other files--but it wouldn't of course impact browser use even if installed by npm). module and browser can be breaking changes too, but I think they are targeting the files that should be expected.
Although I didn't do so, we could add jquery as a peer dependency for Node usage, but Node really needs custom tooling like jsdom as well, so maybe better to avoid the hassle of having to keep peerDependencies up to date.
While I added a few more linting rules for consistent styling, I'd be happy to apply a more rigorous config, e.g., standard, airbnb, etc., if you like.
Builds on #40 (dropping bower).
jQuerymodule,exports,browser, andtypefor ESM usage by bundlers or Nodejqueryinstance (passing in alone not sufficient)A couple notes:
jquery.easing.jsandjquery.easing.min.jsto a newdistfolder, as that should make things a bit cleaner, though it would increase breakage as the path would change.importstatements against jQuery in source would need our adding Rollup's commonjs plugin, and it would have the disadvantage of baking in a specific version of jQuery, adding to bundle size (unless we kept the import statement as an import statement, but then users would have to do their own bundling based on our bundle which isn't very convenient). So, currently, even one of the ESM source files relies on ajQueryglobal, though there is also another source fileaddJQueryEasing.js(in source atsrc/addJQueryEasing.mjs) which allows one to pass in one's own jQuery instance if that is desired. jQuery's current lack of proper ESM export is another reason I didn't bother with a native Node ESM demo, though I tentatively added such support inpackage.json(by thetypeandexportsfields).jsdomto get things working properly (I added a demo that executes without error, but as it is in Node, there is of course no visual effect). Note that CJS support had been broken until recently anyways, so I don't think this necessitates a breaking change (nor, as a result, should I think the addition ofexportsbe so, even though it normally would be a breaking change since it prevents Node access to other files--but it wouldn't of course impact browser use even if installed by npm).moduleandbrowsercan be breaking changes too, but I think they are targeting the files that should be expected.jqueryas a peer dependency for Node usage, but Node really needs custom tooling likejsdomas well, so maybe better to avoid the hassle of having to keeppeerDependenciesup to date.standard,airbnb, etc., if you like.