feat: Add ES6 module export

[spocke]

This PR adds es2015 module support for exports it also compiles those modules in ES2019 syntax format.

I moved the types to a separate file since that made it easier to import them all and re-export them I changed the index so that it's more explicit what functions are being exported.

Had to add roots to jest because it was trying to run the es6 modules though node and that was breaking not sure why not that familiar with jest.

I also added sideEffects: false to the package.json since this module doesn't have any sideeffects from importing a module that I can see so that should reduce the bundle size if you only use the parser for example.

[fb55]

Hi @spocke, thanks for this great PR!

This will already be a breaking change, but I am trying to keep upgrading as simple as possible. That means that I'd like to avoid any changes that aren't necessary for the ES modules conversion. Could you revert eg. removing default exports?

[spocke]

Hi @spocke, thanks for this great PR!

This will already be a breaking change, but I am trying to keep upgrading as simple as possible. That means that I'd like to avoid any changes that aren't necessary for the ES modules conversion. Could you revert eg. removing default exports?

It pretty much compiles to the same thing this is what the default exports index.js looks like:

"use strict";
var __createBinding = (this && this.__createBinding) || (Object.create ? (function(o, m, k, k2) {
    if (k2 === undefined) k2 = k;
    Object.defineProperty(o, k2, { enumerable: true, get: function() { return m[k]; } });
}) : (function(o, m, k, k2) {
    if (k2 === undefined) k2 = k;
    o[k2] = m[k];
}));
var __exportStar = (this && this.__exportStar) || function(m, exports) {
    for (var p in m) if (p !== "default" && !Object.prototype.hasOwnProperty.call(exports, p)) __createBinding(exports, m, p);
};
var __importDefault = (this && this.__importDefault) || function (mod) {
    return (mod && mod.__esModule) ? mod : { "default": mod };
};
Object.defineProperty(exports, "__esModule", { value: true });
exports.stringify = exports.parse = void 0;
__exportStar(require("./parse"), exports);
var parse_1 = require("./parse");
Object.defineProperty(exports, "parse", { enumerable: true, get: function () { return __importDefault(parse_1).default; } });
var stringify_1 = require("./stringify");
Object.defineProperty(exports, "stringify", { enumerable: true, get: function () { return __importDefault(stringify_1).default; } });

This is what the new index.js file looks like:

"use strict";
var __createBinding = (this && this.__createBinding) || (Object.create ? (function(o, m, k, k2) {
    if (k2 === undefined) k2 = k;
    Object.defineProperty(o, k2, { enumerable: true, get: function() { return m[k]; } });
}) : (function(o, m, k, k2) {
    if (k2 === undefined) k2 = k;
    o[k2] = m[k];
}));
var __exportStar = (this && this.__exportStar) || function(m, exports) {
    for (var p in m) if (p !== "default" && !Object.prototype.hasOwnProperty.call(exports, p)) __createBinding(exports, m, p);
};
Object.defineProperty(exports, "__esModule", { value: true });
exports.stringify = exports.parse = exports.isTraversal = void 0;
__exportStar(require("./types"), exports);
var parse_1 = require("./parse");
Object.defineProperty(exports, "isTraversal", { enumerable: true, get: function () { return parse_1.isTraversal; } });
Object.defineProperty(exports, "parse", { enumerable: true, get: function () { return parse_1.parse; } });
var stringify_1 = require("./stringify");
Object.defineProperty(exports, "stringify", { enumerable: true, get: function () { return stringify_1.stringify; } });

Unfortunately rolling it back doesn't work for our use case. We use this with node and .mjs files and there the modules doesn't support the default property at least I couldn't get it to run without getting undefined functions. Also not sure how bundlers deal with export default and tree shaking when the default is a object they tend to not tree shake since it's then a mutable thing so much harder to track.

I could add export default parse; and export default stringify; to both modules if they are imported directly however that would mean that the default will be a function and have a parse property as well for the parse.js module.

[spocke]

Follow up on that mjs issue to reproduce that issue if you use:

import { parse } from 'css-what'

console.log(parse("foo"))

With the default exports approach my node 16 throws this error:
SyntaxError: Named export 'parse' not found. The requested module 'css-what' is a CommonJS module, which may not support all module.exports as named exports.

However with the version in this PR it doesn't produce that error. However the mixed default and direct exports seems to not produce any errors in mjs files so I guess it just favors the es6 modules.

[TheSpyder]

As far as I can tell nobody imports parse.ts and stringify.ts directly, so what they export should make no difference? The index file was already renaming the default function to parse. I don't see how this is a breaking change. If it was, the tests would need to change as well.

[fb55]

Won't imports have to be updated to include a .js extension?

[spocke]

Technically yes in order to get these to work in a browser it needs to have an extension. However both eslink-pluign-node and jest breaks if I change this to have .js extensions.

There is a long thread here:
microsoft/TypeScript#16577

Microsoft don't want to convert these paths to js paths on the fly but they seem to support them now however the rest of the tools for linting and testing here doesn't seem to suppot that. There are workaround for this that for example transpile the js files before being pushed to npm. I've seen people having scripts that just regexp replace this in source. It all depends on how much one want it to work with js modules in the browser. Bundlers will look for default file extensions so this is only an issue if you are loading scripts with <script type="module" src="main.js"></script>.

[fb55]

Is there a way to test the ESM version of the module as well? Eg. if a __dirname was missed somewhere — would that be caught?

[fb55]

Does moduleResolution have to be set here?

[spocke]

If you don't specify node it will classic if you change module to es2015.
Described here: https://www.typescriptlang.org/docs/handbook/module-resolution.html#module-resolution-strategies

[fb55]

Left some comments. Happy to go forward with this, I'm just trying to understand possible gotchas.

[fb55]

Thanks @spocke! Using this as an opportunity to modernize the library a bit more, will get a new release out soon.