Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Import difficulties #4

Open
toreric opened this issue Jul 16, 2024 · 4 comments
Open

Import difficulties #4

toreric opened this issue Jul 16, 2024 · 4 comments

Comments

@toreric
Copy link

toreric commented Jul 16, 2024

I tried to import { SortableObjects, DraggableObject } from 'ember-drag-drop'; but became aware of that the barrel file exports don't exist. Please complete this!

@evoactivity
Copy link

Just for some extra context, the index.js file that the exports field in package.json defines is empty, so using this with template-imports requires tracking down the true location of each component like so.

import SortableObjects from 'ember-drag-drop/components/sortable-objects'
import DraggableObject from 'ember-drag-drop/components/draggable-object'

@toreric
Copy link
Author

toreric commented Jul 16, 2024

So the intuitive way to import cannot ever be used? Then please add some advice about that in the usage section, difficult to just guess those paths, for me at least :)

@mansona
Copy link
Contributor

mansona commented Jul 16, 2024

So the intuitive way to import cannot ever be used

just one quick note on this: it may be slightly easier to import things from a single place but there are two added layers of confusion if you were importing things from the top level like this. Firstly all of the parts of an addon would need to be imported and then re-exported from an "index barrel file", this would essentially negate any tree-shaking that were available.

The second issue you have is that if you have an import like the following

import { someInvokable } from 'my-fancy-addon';

<template>

<!-- is someInvokable a component or a helper!? -->

</template>

as you can see there is some information lost about someInvokable, we don't know if it's a helper or a component if we import through a barrel file.

Then please add some advice about that in the usage section

100% agree, we're going to need to get better as a community at listing the possible points of import in our usage sections 👍 if you can see something that you think should be added feel free to open a PR (even straight from the GitHub UI would be super useful)

@evoactivity
Copy link

Tree shaking can still work with barrel files by setting "sideEffects": false in the package.json
https://webpack.js.org/guides/tree-shaking/#mark-the-file-as-side-effect-free
If the bundler knows your modules are pure then it will drop unused exports, including those in barrel files, this is also supported in vite through rollup.

On your second point I kind of agree, but I also do like being able to import from the top level. So yes, at the point of import you don't know for sure what is a component and what isn't outside of convention (components being PascalCase and helpers being camelCase). If you're the person adding those imports you'd be reading the docs anyway (so you know what components and helpers are available to you), and if you're coming into the file after that, you'd infer it from usage in the template. Most v2 addons I've used up to now have their components importable from the top level.

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

No branches or pull requests

3 participants