{"id":332790,"date":"2021-01-19T10:54:07","date_gmt":"2021-01-19T18:54:07","guid":{"rendered":"https:\/\/css-tricks.com\/?p=332790"},"modified":"2021-01-19T10:54:09","modified_gmt":"2021-01-19T18:54:09","slug":"life-with-esm","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/life-with-esm\/","title":{"rendered":"Life with ESM"},"content":{"rendered":"\n

ESM, meaning ES Modules, meaning JavaScript Modules<\/a>. Like, import<\/code> and friends.<\/p>\n\n\n\n

Browsers support it these days. There is plenty of nuance, but as long as you’ve dropped IE, the door is fairly open.<\/p>\n\n\n\n\n\n\n\n

Before ESM, the situation for JavaScript projects was:<\/p>\n\n\n\n

  1. We’ve got packages we need to use from npm.<\/li>
  2. We’ll install them from npm ahead of time with our package.json<\/code>, npm install<\/code> and whatnot.<\/li>
  3. We’ll write import<\/code> statements that are invalid<\/em> ESM for some reason (developer convenience, I guess) and assume we’re importing packages from a local node_modules<\/code> folder.<\/li>
  4. Our bundler will know what to do with those invalid imports.<\/li>
  5. This is all OK, because word on the street is that bundling is still required for performance, and it does other stuff we want anyway, like run Babel and friends.<\/li><\/ol>\n\n\n\n

    Now that we can count on ESM more, the story is shifting somewhat, and all of those things are being questioned. <\/p>\n\n\n\n