Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Steps to reproduce
What is expected?
The component should be available at:
What is actually happening?
The component is available at:
In v14 it was removed from the code base.
The docs still show it as an option.
Isn't it still a bit premature to remove this option entirely? ES Modules still haven't landed in Node natively. We use CommonJS everywhere to alleviate context switching overhead and allow for isomorphic modules. We don't plan on adding a transpile step to our server-side code, and I don't see many other developers planning to do so either. I understand I could just use
This SO post shows one of the cryptic errors:
See here for the status of ES Modules in Node:
This is an intentional removal (and that's why it's a new major version). We forgot to remove it from the docs when publishing v14. That said, do read the release notes before upgrading major versions!
Currently there are no major new features in v14.0 so you can safely stay on v13.x, but in the long run, you definitely should consider migrating towards ES modules whenever possible.
@BrainBacon for server-side code, I'm not quite following why you'd have the problem if you are using webpack to bundle your code - are you using require hooks to directly load Vue files on the server?
My personal plan is to wait until Node.js ships with ESM (without a flag) and instruct all my developers on it's immediate ubiquitious usage. I do not plan on supporting a fractured code with band-aid tooling just for the time being.
I personally follow ESM very closely for the reason that it's a great standard, and I supported the push away from Node's
There are practical reasons why you should use ESM for client-side code. When you continue to use CommonJS syntax in webpack-bundled code, you won't get any of the three-shaking benefits because they require ESM syntax to work. This means you are likely causing your client-side payload to be bigger than it should be when you stay on CommonJS.
IMO that alone is worth using ESM for client-side code. Plus, I myself have been writing client-side code in ESM and Node code in CommonJS concurrently for quite some time and haven't really find the context switch cost noticeable.
If you insist on staying on CommonJS, you can write a custom babel plugin that appends
I may not have been entirely clear about how adopting ESM too quickly can hinder progress. There are road blocks to confidence in ESM at this point. The Babel/Webpack implementation is non-standard and developing ESM in it's current format could prove to lead libraries into an unsupported dead-end. Here's a pull-request in Babel that showcases the uncertainty facing ESM implementation. If libraries choose to continue down this path early, then the possible price to pay in the future of the library is incompatibility with the final standard. Vue is not the only library headed down this path and it causes self-reflection in the community on weather or not to adopt something non-standard over standards because it's "the way we're already doing it!"
I definitely understand the practicality of tree-shaking and other benefits of ESM and I don't disagree. I think developers that want that functionality today are well within the scope of Vue's progressive vision, but forcing the entirety of the community to adopt a technology that isn't ready is a bit unreasonable. Shouldn't the term "progressive enhancement" apply here?
I think the way it was handled before was fine. Was there a technical limitation to maintaing multiple distributions in this library specifically? Couldn't we just have a
Edit: now that I think about it, it would require different logic in the library for converting the transpiled module code. Please disregard my suggestion for a different distribution.
Maintaining parallel support for both ESM and CommonJS in