-
Notifications
You must be signed in to change notification settings - Fork 825
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
Replace browserify/gulp with Webpack #5918
Conversation
One think I notice is that it appears there isn't an explicit set to |
Hey Sam, this looks awesome! Could we either move this to the open-sausages repo, or give me temporary commit rights on your fork? I could also send pull requests to your fork, but that seems a bit overkill :) Converted https://github.com/open-sausages/silverstripe-framework/tree/webpack I got a bit confused by the
We have to fix the 4.0 changelog referencing build tooling as well as docs references to browserify: |
@sminnee Done some more work on this (in the open-sausages branches). Kept your commits intact to make review easier, we'll need to squash a bit once you're happy with my modifications. I now know why you didn't use Added some TODOs to the PR description. I've done a bit of testing, looks good in IE10 and Chrome (main interactions, no missing files, no console errors). A full Behat run should uncover things pretty well |
Talked to Sam and decided to push my commits to https://github.com/sminnee/silverstripe-framework/tree/webpack |
@@ -1,4 +1,4 @@ | |||
window.tmpl.cache['ss-uploadfield-downloadtemplate'] = tmpl( | |||
tmpl.cache['ss-uploadfield-downloadtemplate'] = tmpl( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could add window.tmpl
like in UploadField_uploadtemplate.js
for consistency, not a breaking change
@chillu I think that the partial revert of the dist rebuild is a bit excessive. Having done a search through the code for framework/admin:
framework:
cms:
installer, asset-admin, siteconfig, reports: none |
@sminnee I've pushed an update (and squashed). It's less about Added a few TODOs at the top. What's your take on copying and sanity checking (diffing) third party code? Ideally we can get proper ES6 exports for those, not sure if anything has changed since we last looked at those particular libs. @unclecheese We've talked about updating build tooling docs for SS4 on Twitter the other day. I've had to rewrite some of this in this PR as part of the Webpack switch, and restructured it a bit while I was going as well. Wanna have a read? Does the |
Talked a bit more with Sam offline:
We've been able to remove nearly a THOUSAND FRICKEN NPM PACKAGES by switching to Webpack (and simplifying the build, e.g. no more spriting and coffeescript processing) - a full third less. Before
After
|
Further to the point of loading TinyMCE via the PHP GZIP script: An example of procedural plugin registration, and the corresponding add() API. If we keep a list of pre-bundled default plugins in our own |
@flamerohr added a react-based mini-pattern-lib to frameworktest via silverstripe/silverstripe-frameworktest#22. Which means we should migrate this to Webpack as well |
Facebook has released a https://github.com/facebookincubator/create-react-app/blob/master/config/webpack.config.dev.js |
I got this error running
|
For some weird reason, |
It's caused by https://bugs.jqueryui.com/ticket/9316. widgetEventPrefix is empty, so I think it's a bit beyond me to figure out how it's being broken... I might need to leave it to a frontender. =( |
@sminnee I think we’re hitting this for Webpack’s TextExtract loader: webpack-contrib/extract-text-webpack-plugin#179 - basically it silently fails to merge multiple entry points into a single CSS file. It works with a I'll comment out all the |
Yeah good approach to get this over the line. We can refine later if we want. |
I've had to back-port the above bugfix into our copy of jquery-ui.js, which is currently at 1.9. I attempted to upgrade to ui 1.10.4, but this would require us to re-do all our code which relied on .data() behaviour from 1.8, which is a breaking change. |
I've fixed pretty much all that I can... the only remaining issue blocking tests passing is the |
When adding the deps straight into the file (recommended), the onchange handler in file-upload isn't firing properly when a file is uploaded through the <input type=file> button - it falls back to default behaviour, which submits the containing form, failing because the upload is handled by a different URL.
OMG, I think this is actually ready to merge now! Behat and PHPUnit tests are passing locally for me. There's one test failure which is due to changed paths in the "simple" theme (silverstripe/silverstripe-simple#42, |
@@ -106,7 +106,7 @@ public function getPreviewURL() | |||
} | |||
|
|||
// Default media | |||
return FRAMEWORK_DIR . '/images/default_media.png'; | |||
return FRAMEWORK_DIR . '/client/dist/images/src/default_media.png'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we squash this back to "FIX Webpack handles images & fonts"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit hard to tell which commit this belongs to, since that line has been changed in the PR afterwards - I'd say just leave it here, unless you can point out a commit
OK I've reviewed Ingo's changes to this and I'm happy, assuming the tests pass. |
@@ -3,6 +3,8 @@ | |||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't see how this file is actually getting included, and my suspicion is that the code is so edge-case that tests don't file if we remove it entire.
Can we see some evidence that the .cms-content-tools #Form_SearchForm
entwine rule has been bundled?
If not, do we need to include these files in the bundle-legacy entrypoint?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I've added it to legacy.js
now and verified that the "expand csv stuff" feature works in ModelAdmin (so the JS kicks in)
There's not a lot of benefit in packaging these separately in terms of initial CMS load size, so let's simplify the setup. They'll eventually become lazy loaded chunks in a React-based setup
Used in iframe, so can't be rolled into other code. Moved in admin/ since that's easier for now with Webpack entry points, and we'll move all JS/CSS into admin/ anyway soon.
We've removed the ability to directly reference JS and CSS files for form fields and other SilverStripe features in favour of a common bundle built by Webpack. The logical next step is to make the framework module free of frontend dependencies, which should simplify its operation, and avoid another time intensive "npm install" on a module.
The JavaScript i18n functionality in SilverStripe is used in the CMS as well as form field implementations. Form fields used to include their own JavaScript for usage outside of CMS. This now requires custom build tooling in a project. Hence there's no need for an i18n shim (i18nx.js), since the CMS always uses i18n support.
Storing in fonts/, not font/fonts
Multiple entry points can't result in a single bundle.css with a fixed filename, see webpack-contrib/extract-text-webpack-plugin#179 Until that's resolved, it's easier to keep the 'css' task separate in Webpack, and have a single entry point for all CSS (bundle.scss). Also partially reverting "Moved frontend assets into admin/ "module"", which moved too many files: debug.css and install.css need to remain as framework (not admin) deps. Split out into a separate `framework-css` Webpack task in preparation for splitting off the module.
We don't have an easy way to copy over those files automatically into the thirdparty/ dir, where they are accessible on the webroot (not the case in node_modules). To avoid confusion, we don't duplicate into node_modules for now. See #5918 (comment)
They were used for TreeDropdownField JavaScript tests but were never run on CI, hence have been a bit of a wasted effort. We're using a different JS unit testing solution now (geared towards React), and running Jasmine in parallel on Travis for a few test cases doesn't warrant the setup effort involved. The TreeDropdownField component will eventually move to a React solution which can be developed in a test-driven fashion.
The 'admin' module will be split off from 'framework', where 'framework' only provides (mostly) frontend-agnostic PHP classes. For example, HTMLEditorField.php has a TinyMCEConfig.php driver, but doesn't come with its own JS includes.
When rewriting the i18n.js file from ES5 to ES6, the detectLocale() call in the constructor was missed - meaning the lang files were loaded by the browser, but never actually used.
We're no longer copying JS sources around, hence there's no need for this task.
OK all tests except the CMS ones pass. @tractorcow do you want to merge this? |
I've merged cms + testsession, restarting framework build. |
@tractorcow we're green. :-) I'm merging |
Details in the commits, feedback welcome!
Pull requests:
silverstripe/silverstripe-cms#1589
silverstripe/silverstripe-asset-admin#249
silverstripe/silverstripe-testsession#41
silverstripe/silverstripe-reports#48
silverstripe/silverstripe-simple#42
TODO
Implement sprite generation(decided it's no longer required)Document dependencies being copied manually into thirdparty (e.g. TinyMCE)Actually just removedtinymce
from NPM deps, since we're not using it (only the manual copy inthirdparty
). Can be added back once we implement my suggestion in comments below.Notes
framework/thirdparty