Publish ES2015 module in NPM package.

[MicahZoltu]

Process for publishing CommonJS + ES2015 module version:

1. Create a second tsconfig-es.json (can extend the current one as the base).
2. Set "module": "es2015" in tsconfig-es.json
3. Set "outDir": "lib-es" in tsconfig-es.json
4. Set the following keys in package.json (https://nodejs.org/api/esm.html)

   "type": "commonjs",
   "main": "./lib/index.js",
   "exports": {
       "import": "./lib-es/index.js",
       "require": "./lib/index.js"
   }
   

No webpack is necessary here, if users want to bundle they can do so. By not using a bundler in the library, it makes it easier for applications to do tree shaking if desired. That being said, if bundling is desired, you may need to use a different bundler that supports ES output like rollup or something.

[mrhut10]

hay @MicahZoltu I've got a branch which is a rewrite which isn't quite ready for a PR yet (haven't actually imported and tested it yet) but i've removed bundling as a step completely. figured what ever codebase imports this as a NPM package should be responsible for their own bundling or / tree shaking as you say.

by removing those bundling dependencies like webpack and babel and just using tsc the depenancies tree drops in count from 421 to 21 or something as well.

again not quite ready for PR but wellcome to have a quick look at the branch diff and comment back https://github.com/Vashnak/react-toasts/compare/master...mrhut10:rewrite

[MicahZoltu]

Out of curiosity, why are Babel types still required? https://github.com/Vashnak/react-toasts/compare/master...mrhut10:rewrite#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519R50

[MicahZoltu]

Note: That branch still targets commonjs, which means it cannot be used natively still.

[mrhut10]

yeah good point on the Babel types I did remove them initially but typescript then complained, I'll retry to remove them

Out of curiosity, why are Babel types still required? master...mrhut10:rewritediff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519R50

good question I did have it removed initially but typescript then complained, I will look at removing that again.

[mrhut10]

Note: That branch still targets commonjs, which means it cannot be used natively still.

right, so you'd prefer it targeted es5? rather than supporting both if it was moved to just target es5 would be there any downsides?? IDK changing it over to es5 assuming it isn't going to break anyone's sites thats using it.

[MicahZoltu]

right, so you'd prefer it targeted es5? rather than supporting both if it was moved to just target es5 would be there any downsides?? IDK changing it over to es5 assuming it isn't going to break anyone's sites thats using it.

I generally recommend having two tsconfig files that target different module systems. That way people who are using commonjs build tools can continue to do so, and people using es2015 build tools or running natively in the browser can choose to do so.

If you only target es2015 modules then people using legacy build tools will run into problems, so I don't recommend a hard switch-over. Luckily, package.json supports specifying multiple entrypoints depending on environment so you can just support both without most of your users even realizing it.

[Vashnak]

Luckily, package.json supports specifying multiple entrypoints depending on environment so you can just support both without most of your users even realizing it.

I did not know, interesting point