-
-
Notifications
You must be signed in to change notification settings - Fork 133
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
Proposal: Make Webpack the default CLI bundler option #833
Comments
I, for one, welcome our webpack overlords. Also, I'm in favor of this proposal. |
Pleae consider also —i-know-what-im-doing flag |
Meh, not really a fan of Webpack ... what a surprise :), but I see the case and especially that first steps become much less troublesome, although you sacrifice flexibility and the features of a real loader for extended use cases. |
@zewa666 choice is good when you know how to choose. It is good to inform about different options after newcomers get a taste of goodness. And face real difficulties. |
@zewa666 do you mean there is on-going effect to remove the api? can you share a link? |
There is an active PR but for the sake of it i cant remember where i've seen it. @bigopon was working on it |
The PR is here aurelia/framework#858 It is useful for plugins distribution, as it helps distributing whole plugin as 1 file easily, but not so much with application development as messing with Origin / file path is quite annoying for requiring sub modules inside view templates. Could help with scenarios where multiple teams are working on same project, each team could distribute their features as a single bundle though |
I ask this because I have bit interest to add support of There is a chance to drop I want to live without knowing webpack. @bigopon your PR means I don't have to touch (or say less demanded) tracing code, cannot wait for it to be merged. But anyway, I have no commitment (spare time) to implement my idea in near future. |
I think @JeroenVinke already did the switch for WebPack being default in this commit and new version 0.33.0 seems to have it merged as well. |
Correct :) |
Hi guys, I wrote some code to backup my mouth. #862. |
I'm submitting a feature request
Current behavior:
The Aurelia CLI recommends RequireJS as the default bundling option of choice. Although RequireJS is battle-tested and works, it requires a little more work to add in dependencies (namely inside of your
aurelia.json
file).After reading this article the author runs into a few issues with adding in third-party libraries due to the required step of needing to add things into the bundles' section and when dealing with fonts in Font Awesome, needing to create a gulp task.
I understand that the CLI added in the
add
andimport
commands for automating the process of installing and adding dependencies into theaurelia.json
bundles section, but many do not know about this and they don't always work for every package (particular packages exporting both Javascript and CSS).I agree that this kind of workflow in 2018 when Webpack has all but become the golden standard for bundling, is painful. And I believe that this might be tripping up less experience and experienced developers alike.
What is the expected behavior?
I propose that Webpack becomes the default bundler choice.
What is the motivation / use case for changing the behavior?
Developer experience is negatively impacted as a result of having a bundles section in
aurelia.json
and packages with CSS, Fonts and Javascript make it even more complex (especially whenau add
andau import
fail to add the dependencies properly).The text was updated successfully, but these errors were encountered: