Update sample-rollup.config.js #1012
Conversation
| // This tells rollup to follow the node-resolution algorithm for finding | ||
| // dependencies / and files within those dependencies | ||
| nodeResolve({ extensions }), |
There was a problem hiding this comment.
In general, I don't think we want folks to do this. This will make rollup embed your dependencies (not allow them to be resolved at application build time), which would be quite unfortunate. It would mean that the addon author in question would have to redeploy a new patch release for any security/patch releases in dependencies...
More details below in the externals section.
| // This provides defaults that work well alongside `publicEntrypoints` below. | ||
| // You can augment this if you need to. | ||
| output: addon.output(), | ||
|
|
||
| // This prevents peerDependencies from being included in your bundle | ||
| external: Object.keys(packageJson['peerDependencies']), |
There was a problem hiding this comment.
This is great! We need to beef it up though, it should also include:
- The list of Ember's pseudo packages (e.g.
@ember/objectand friends). We should get that list from@embroider/shared-internalsand expose it on theAddoninstance we are using here. - The list of dependencies (the actual resolution / bundling will be done by the final app packager; either ember-auto-import@2 in classic builds or @embroider/webpack in Embroider builds)
| import { Addon } from '@embroider/addon-dev/rollup'; | ||
|
|
||
| import packageJson from './package.json'; |
There was a problem hiding this comment.
Hmm, what makes this work? By default you can't import from .json files in Node...
There was a problem hiding this comment.
Rollup configs go through their own weird preprocessing. That's also why they're written as ES modules despite predating Node's native ES module support.
| const addon = new Addon({ | ||
| srcDir: 'src', | ||
| destDir: 'dist', | ||
| }); | ||
|
|
||
| const extensions = ['.js', '.ts']; |
There was a problem hiding this comment.
If we remove nodeResolve, I think we ought to be able move this to inline with babel with a nice little comment?
|
I don't think we want Even in cases where rolling up a dependency is desired, it's only appropriate to do that for So I think the real bug here is that we're letting rollup emit misleading warnings. The current output is correct, we just want to stop the warnings. I can whip up another little plugin to put in the default config that will achieve that. |
|
Here's how I would prefer to deal with the standard externals: #1015 |
|
legit, I'll rebase and update this once that's merged |
NullVoxPopuli
force-pushed
the
patch-1
branch
from
2ce525e
to
5024010
Compare
|
Should we close this now that #1015 landed? |
|
I think the updates cover the dependency aspect of what I was trying to solve. Should we still keep the |
|
I think this use of extensions is misleading. It makes it look like the config supports TypeScript, but it does not. For TS you still need to also add We should probably be moving toward maintaining real blueprints rather than just this example file, in which case we could maintain a typescript blueprint that extends the base one, and that would be a good place to put all this. |
|
Sounds good! |
Adds some things I encountered while setting this up: https://github.com/NullVoxPopuli/ember-resources/blob/main/ember-resources/rollup.config.js