Skip to content
This repository has been archived by the owner on Sep 2, 2023. It is now read-only.

Feature: Transparent migration #105

Closed
GeoffreyBooth opened this issue May 20, 2018 · 5 comments
Closed

Feature: Transparent migration #105

GeoffreyBooth opened this issue May 20, 2018 · 5 comments
Labels

Comments

@GeoffreyBooth
Copy link
Member

GeoffreyBooth commented May 20, 2018

As I’m gradually migrating my CommonJS package to ESM one file at a time (see also #99 and #90), I can do so without needing to know or look up the module types of my dependencies. I don’t need to rely on dependencies’ READMEs or package.jsons or source code to know their module types, nor do I need to resort to trial and error.

This migration of my package does not cause a breaking change for any apps using my package’s API, nor for any apps importing my package as a dependency.

When I’m done migrating to all import and export statements, I can remove the Babel modules transform (or my entire build step) and the package functions the same as before.

Use cases 18, 20, 39, 40.

@ljharb
Copy link
Member

ljharb commented May 20, 2018

This relates heavily to #90; if "no transparent interop" is decided, this use case becomes impossible.

@xtuc
Copy link
Contributor

xtuc commented May 21, 2018

That really depends on your workflow/toolchain.

The one that we're trying to push at Babel is the babel-preset-env approach. The user don't need to worry about CJS or ESM because the preset will decide which one to pick based on the target.

The conclusion is that it will be transparent for the user and I think that's a good thing.

@bmeck
Copy link
Member

bmeck commented May 23, 2018

@xtuc the problem is the output variances of the Babel ESM->CJS transform with how ESM can import things according to spec / VM. See #90 and related issues.

@guybedford
Copy link
Contributor

This sounds to me more like an issue of "importing a dependency without needing to know the module type" than gradual migration of source text goals, which already seems to be tracked in #99.

I'd like to propose changing the name to "Format-independent imports" or similar, including in the README reference.

@demurgos
Copy link

demurgos commented Jul 18, 2018

🚲 🏠 I like the name "Agnostic consumer" defined in one of the terminology Google docs. I feel that it better put emphasis on the fact the consumer does not know the module type of the dependency.

The kind of imports compatible with agnostic consumers may be roughly ordered by "strength": simple bare specifiers (package main), intra-package, extra-package deep imports. Some proposals do not support it at every level. #99 seems to be focused on intra-package imports.

See also #138 for more discussions about "transparent interop".

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

6 participants