emberjs / rfcs

RFCs for changes to Ember
https://rfcs.emberjs.com/
794 stars 407 forks source link

Could Ember adopt the Node module resolution strategy? #761

Closed shama closed 2 years ago

shama commented 2 years ago

What? With Ember >= 3.13, doing yarn add ember-source creates a folder structure for most of the modules in node_modules/ember-source/dist/

Ember uses a custom module resolution strategy, for example ember-source/dist/packages/@ember/component/index.js has:

export { setComponentTemplate, getComponentTemplate } from '@glimmer/manager';
export { Component as default, Input } from '@ember/-internals/glimmer';
export { componentCapabilities as capabilities, setComponentManager } from '@ember/-internals/glimmer';

Where @ember and @glimmer are aliases to other folder paths that only Ember CLI knows how to resolve. There are also some modules it just knows to look for in ember-source/dist/dependencies and some provided elsewhere (e.g. at one point in Ember version history, @glimmer/env was a separate package you know had to know to install and wire up).

Why? The Node module resolution strategy is extremely popular and as such there are a lot of tools that work with that module resolution strategy out of the box.

We would be able to yarn add ember-source and use a tool like webpack or rollup to import { Component } from "ember-source/dist/packages/@ember/component" without having to know how to wire up all the custom Ember alias module names.

Or, in my current desired use case, wanting to build cross platform components using Kotlin Multiplatform with Ember. The current state of KMM tooling for JS works out of the box with the Node module system because it is the most commonly used. For example, you can already use React with KMM because React uses the Node module resolution.

If Ember adopted the Node module strategy, it would make it possible for people to integrate Ember into their existing build system or other contemporary build systems.

Alternative Solutions Maybe switching the module resolution isn't practical or desired by the team still at this point. How about releasing a npm/yarn friendly package of Ember instead?

Where one could do yarn add @ember/source and then use the Node module system to do:

import { Component } from "@ember/source"

Or at the very least a package, file or utility that one could use to know that "@glimmer/manager" within packages/@ember/component/index.js means to look "../../dependencies/@glimmer/manager.js?

Thanks!

pzuraq commented 2 years ago

@shama Ember is currently in a transition process toward using the NPM resolution strategy. This is part of the wider Embroider effort, and while Embroider will still ship before it's fully complete, this is definitely the long term goal. If you'd like to help out with the effort, we could definitely use more help! I'd suggest reading the RFCs on Embroider to understand the goals there as a starting point.

shama commented 2 years ago

@pzuraq Oh I totally missed this RFC. I previously thought Embroider was just going to be an addon. That is great to hear the long term plan is to adopt that resolution strategy internally. I will look to see if I can help out with those efforts there. Thanks!