There's a large portion of the Node ecosystem that isn't particular to Node.js itself. Is that good for the state of the web? Read on to get one dev's take.
Join the DZone community and get the full member experience.Join For Free
I've got thoughts on the post I did about ES Modules.
I couldn’t find a lot of guidance on what to do here, so I went to experiement and this solution is the solution I came across:
- Create a file that imports the npm module I needed.
module.exports = require(‘get-urls’);This module will be what’s converted to ES6 style.
- Create a rollup config that:
- Imports the node globals, and built-ins.
- Resolves all npm modules required for my usage of this module.
- Compress the output, because it’s huge.
- Include the bundled file in your project and rejoice."
One of the things that I wanted to try and articulate in the original article but I decided to pull out is that there is a huge amount of code in the Node ecosystem that is not really that specific to Node per se but has been tightly coupled with Node via Common JS and other very specific Node APIs (Buffer, old URL, etc., etc.) that it's going to take a lot of effort to pull ourselves up and thus the change be required to make ES Modules ubiquitous will be potentially quite painful, and until the ecosystem changes we are going to need to use a lot of conversion tools and bundlers to be able to cleanly share code across multiple platforms (web/server).
We are where we are, there wasn't an importing story on the web, we didn't have a heap of the primitives that Node introduced and are now what many would now consider de-facto platform requirements, so I hope that this is more of an acknowledgment of the situation than a criticism.
Lots of fun times ahead, I for one am looking forward to being able to bring a lot more functionality to the web.
Published at DZone with permission of Paul Kinlan , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.