A question about scoped imports

WeaselScience · February 28, 2017, 2:38pm

I’ve made some tests regarding scoped importing, and it seems like Meteor supports importing files directly from another package. For instance, if I have a package test-export, which has a file test.js, which in turn does export default 'Hello World!', I can, in another package which depends on test-export, perform import test from 'meteor/test-export/test.js'; console.log(test); and receive Hello World! in my console.

I could not find something official about this in meteor documentation. Is this feature “stable” and is safe to use long-term? Or is this some sort of a side effect? @benjamn maybe you can tell something specific about this?

robfallows · February 28, 2017, 2:47pm

Yes - import has been supported since 1.3:

github.com

meteor/meteor/blob/devel/History.md#es2015modules

## v.NEXT

* The `meteor-babel` npm package (along with its Babel-related
  dependencies) has been updated to version 7.0.0-beta.35, a major update
  from Babel 6. Thanks to the strong abstraction of the `meteor-babel`
  package, the most noticeable consequence of the Babel 7 upgrade is that
  the `babel-runtime` npm package has been replaced by `@babel/runtime`,
  which can be installed by running
  ```js
  meteor npm install @babel/runtime
  ```
  in your application directory. There's a good chance that the old
  `babel-runtime` package can be removed from your `package.json`
  dependencies, though there's no harm in leaving it there. Please see
  [this blog post](https://babeljs.io/blog/2017/09/12/planning-for-7.0)
  for general information about updating to Babel 7 (note especially any
  changes to plugins you've been using in any `.babelrc` files).
  [PR #9440](https://github.com/meteor/meteor/pull/9440)

* The previously served `/manifest.json` application metadata file is now

This file has been truncated. show original

Non-top-level import has been available since 1.3.3:

github.com

meteor/meteor/blob/devel/History.md#v133-2016-06-10

## v.NEXT

* The `meteor-babel` npm package (along with its Babel-related
  dependencies) has been updated to version 7.0.0-beta.35, a major update
  from Babel 6. Thanks to the strong abstraction of the `meteor-babel`
  package, the most noticeable consequence of the Babel 7 upgrade is that
  the `babel-runtime` npm package has been replaced by `@babel/runtime`,
  which can be installed by running
  ```js
  meteor npm install @babel/runtime
  ```
  in your application directory. There's a good chance that the old
  `babel-runtime` package can be removed from your `package.json`
  dependencies, though there's no harm in leaving it there. Please see
  [this blog post](https://babeljs.io/blog/2017/09/12/planning-for-7.0)
  for general information about updating to Babel 7 (note especially any
  changes to plugins you've been using in any `.babelrc` files).
  [PR #9440](https://github.com/meteor/meteor/pull/9440)

* The previously served `/manifest.json` application metadata file is now

This file has been truncated. show original

benjamn · February 28, 2017, 4:36pm

Yes, importing specific files from other packages is a deliberate and reliable feature. It even works with dynamic import(...) (try Meteor 1.5-beta.8). We may at some point allow packages to prevent some files from being imported, using an API in package.js, but we haven’t seen an urgent need for that yet.

Note that this behavior is very similar to the way Node/npm work when you require("babel-runtime/helpers/typeof") (for example). The package.json file is ignored (in fact babel-runtime has no package.json file) because you’re asking for a specific file.