Soo... I thought this was a competitor to Yarn or NPM itself from the title... It's not. It's for publishing NPM packages. It'd be nice if the title of this was what they have on their site as it more accurately describes what this is: "npm package building, reimagined."
Strange, the title felt pretty accurate to me. I had a good sense of what I was about to read (basically guessed it would handle TypeScript from the title), and then was impressed with the additional features.
First, I really like the idea behind this. All the babel rollup typescript stuff is a big mess when trying to publish a package.
That said, I feel like the authors made some choices that make their lives easier at the cost of having shipped a virtually useless tool. For example:
- The standard typescript builder can only generate ES2018
- The web bundler can only generate ES modules
These two together means that your package won't work on anywhere but the most modern browsers and Node versions, except if your package's users somehow configure their Webpack (or whatever) to run your module through Babel (totally beating the purpose of all this). This is exactly the kind of complication I'd want tools like these to solve for me.
Sure, there's a place for the "this will only work on cutting edge environments", but i'm not sure a tool intended for publishing reusable libraries is that place.
Additionally, a core feature I miss is the ability to have different entry-points for different environments (eg one for node and one for browsers). My library uses the DOM for some heavy lifting and imports JSDOM on Node for that - I'd not want to ship JSDOM to the browser and bloat the download for no reason.
Hope all this improves, I could see myself using this.
YMMV but http://gs.statcounter.com/browser-market-share/desktop/world... points to IE at 5.74%, FF at 9.5%, Chrome at 70.88% in January 2019. Of course, you should look at your own user logs to determine usage statistics, but many government sites still recommend using IE.
Also internationally, some countries have disproportionate IE usage and dropping it basically drops that market. In some market segments, IE users also spend more $$$ per user because of corporate customers. It can be really expensive to give up. If your market is young affluent westerners with MacBook pros it might be easier
Maybe in another five years my company can dump IE, but for now we still have about 1% of paying users chugging along on IE 11, and getting them to update soon is a long stretch given that most of this industry still runs on fax machines.
Depends on your audience. If you are B2B, dropping IE means dropping a financially significant chunk of the market. Heck, we were still getting traffic from people using IE9 in the last year, though it was small enough we were able to convince the whole team that it was time to drop support for everything below IE11. Sorry, poor IE9 user :(
For you use case you just have to make JSDOM an external package (assuming you use webpack or rollup) and declare it as a peer dependency of your package
My old workplace (left 4 months ago) is on the verge of dropping IE11 altogether, and as of my leaving, already was only supporting it as a "won't be totally messed up". That's a medium-to-large sized web agency for our sector. IE11 and lower represent sub ~3% of all traffic according to caniuse, people are slowly dropping it.
Only field where I can see this being totally irrelevant is stuff like public sector/uptight corporate intranet with computer still on W7 without any other browser installed than IE9, or very high traffic/wide public stuff. Otherwise IE is starting to fall out of style faster and faster these days.
From what I learned from digging into Pika/Pack a bit, I think you misrepresented it a bit.
> - The standard typescript builder can only generate ES2018
That's true, but only because the compilation to previous ES versions is meant to be handled by other plugins. For instance, the "web" plugin [1] uses babel-preset-env, which in turn will take your package.json's "browserslist" [2] into account.
> - The web bundler can only generate ES modules
The Pika project seems to be all about promoting ES modules, so it's no wonder that put this option to the forefront. However, there is also an UMD plugin [3] and a "node" (presumably Common.js) one [4].
I've always thought that we should publish our sources to NPM, then during the `npm install` phase, the sources would be compiled (if needed) to your project's settings.
That's not exactly what I meant. I was thinking something along the lines of a more universal way for npm to serve up compatible code without the package publisher having to pre-compile everything to make it compatible with every possible usage scenario. I'm not exactly sure how that would work, but I think it's a bad idea to push all that to package publishers .
22 comments
[ 1.7 ms ] story [ 67.5 ms ] threadThat said, I feel like the authors made some choices that make their lives easier at the cost of having shipped a virtually useless tool. For example:
These two together means that your package won't work on anywhere but the most modern browsers and Node versions, except if your package's users somehow configure their Webpack (or whatever) to run your module through Babel (totally beating the purpose of all this). This is exactly the kind of complication I'd want tools like these to solve for me.Sure, there's a place for the "this will only work on cutting edge environments", but i'm not sure a tool intended for publishing reusable libraries is that place.
Additionally, a core feature I miss is the ability to have different entry-points for different environments (eg one for node and one for browsers). My library uses the DOM for some heavy lifting and imports JSDOM on Node for that - I'd not want to ship JSDOM to the browser and bloat the download for no reason.
Hope all this improves, I could see myself using this.
https://www.npmjs.com/package/@pika/plugin-build-umd
Only field where I can see this being totally irrelevant is stuff like public sector/uptight corporate intranet with computer still on W7 without any other browser installed than IE9, or very high traffic/wide public stuff. Otherwise IE is starting to fall out of style faster and faster these days.
> - The standard typescript builder can only generate ES2018
That's true, but only because the compilation to previous ES versions is meant to be handled by other plugins. For instance, the "web" plugin [1] uses babel-preset-env, which in turn will take your package.json's "browserslist" [2] into account.
> - The web bundler can only generate ES modules
The Pika project seems to be all about promoting ES modules, so it's no wonder that put this option to the forefront. However, there is also an UMD plugin [3] and a "node" (presumably Common.js) one [4].
[1]: https://github.com/pikapkg/builders/tree/master/packages/plu... [2]: https://github.com/browserslist/browserslist [3]: https://github.com/pikapkg/builders/tree/master/packages/plu... [4]: https://github.com/pikapkg/builders/tree/master/packages/plu...
npm install some-library -type umd
and have npm server handle this automatically.