Skip to content

Proofreading webpack.config.js for clarity #440

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

Merged
1 commit merged into from
Jul 31, 2018
Merged

Proofreading webpack.config.js for clarity #440

1 commit merged into from
Jul 31, 2018

Conversation

weaverryan
Copy link
Member

Q A
License MIT

Re-reading the default webpack.config.js file for clarity. I'm also updating the documentation at the moment, and will base those changes off of this.

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request passes validation.

@weaverryan weaverryan changed the title Proofreading webpack.config.js for clarity [WIP] Proofreading webpack.config.js for clarity Jul 19, 2018
Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request passes validation.

Copy link
Member

@javiereguiluz javiereguiluz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really nice changes 👌 Thanks Ryan!


.cleanupOutputBeforeBuild()
.enableSourceMaps(!Encore.isProduction())

// the following line enables hashed filenames (e.g. app.abc123.css)
// enables hashed filenames (e.g. app.abc123.css)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a hint telling that it's a good practice to use it conjointedly with framework.assets.json_manifest_path?

.enableVersioning(Encore.isProduction())

// uncomment to define the assets of the project
//.addEntry('js/app', './assets/js/app.js')
//.addStyleEntry('css/app', './assets/css/app.scss')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As you added a default JS entry, why not add one for CSS too?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

addStyleEntry is kind of an anti-pattern. So, I doc'ed it, but people shouldn't really need to use it, if they want to do things correctly.

@weaverryan
Copy link
Member Author

Thanks for the reviews! I've got a WIP on this, so that I can create a corresponding PR to the docs so that everything is consistent (and we can merge at nearly the same time). I'll ping back when that's ready :)

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request passes validation.

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request passes validation.

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request passes validation.

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request passes validation.

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request passes validation.

* Adding initial js and css files

* removing sass by default to avoid needing extra packages

* enabling notifications
Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request passes validation.

@weaverryan weaverryan changed the title [WIP] Proofreading webpack.config.js for clarity Proofreading webpack.config.js for clarity Jul 27, 2018
Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request passes validation.

@weaverryan
Copy link
Member Author

This is ready for review! The big differences are that I created an app.js and app.css file with basic contents. The idea is that we recommend every app always start with these files, and these will be included in the layout. If it's an SPA or simple app, it's all they'll need. If they want page-specific JavaScript, then they'll add more entry files.

I've updated the docs with this change in mind: symfony/symfony-docs#10128

@ghost ghost merged commit 1e413c6 into symfony:master Jul 31, 2018
ghost pushed a commit that referenced this pull request Jul 31, 2018
@weaverryan weaverryan deleted the encore-webpack-tweaks branch August 4, 2018 01:17
weaverryan added a commit to symfony/symfony-docs that referenced this pull request Aug 4, 2018
…weaverryan)

This PR was squashed before being merged into the 3.4 branch (closes #10128).

Discussion
----------

[WCM] Updating the Encore documentation + New recipe

See symfony/recipes#440

Basically, after a year+ of using Encore, I updated the recipe to follow best practices & clarity. This updates the docs to follow that recipe. Hopefully it makes Encore even more accessible :).

Cheers!

Commits
-------

9b53860 [WCM] Updating the Encore documentation + New recipe
This pull request was closed.
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

Successfully merging this pull request may close these issues.

5 participants