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
Provide support for webpack>=2.6 #6
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- The version is tracked to the major.minor for the release for the mean time, until a more loose setting can be derived. - Only test equality of prebuilts for those versions available.
- Given that webpack 4 provides a set of new keys which may or may not be useful, provide some base support for that such that by default, the warning generated may be silenced if that version is provided. - This paves the way to address differences between webpack versions, such that a wider range of webpack version may be used, so that the expected behaviors may be more easily preserved whenever possible.
- This permit a common and dedicated access to the same method of acquiring the location of the webpack binary in the same manner as the way the WebpackToolchain does it.
- Hook the karma and toolchain config generation to make use of the webpack configuration setup.
- Given that window instead of this is now passed in webpack 4, change around how the invocation is done in node such that the previously established behavior is maintained when it comes to the short-circuit testing through Node.js.
- Some versions of webpack-karma + webpack will simply sit around idle forever whenever webpack fails to build. This injects a plugin into the configuration such that whenever webpack fails to build, have it kill itself.
- Rather than making the assumption about the positioning of the files, extract the first object present in the source as that is currently where the generated base configuration definition sits.
- Implement the base datatypes to ease the creation, manipulation and management of webpack configuration scripts to be generated.
- Provide a helper function that will locate a property and inject the relevant array items into the object, or assign the array as new property; this is for internal use as the implementation is extremely naive.
- Introduce a __webpack_target__ key to the configuration mapping such that the information is persisted when the mapping instance is casted to a standard dictionary. - Also no longer store the ast too prematurely, and break up the whole serialization process into separate methods to permit better reuse.
- Provide a function that will process the webpack config object AST such that version specific flags are produced to avoid conflicts.
metatoaster
force-pushed
the
webpack_4
branch
2 times, most recently
from
August 20, 2018 02:15
ff882aa
to
e3b0a0b
Compare
- Formalize certain method names such that the mapping (and maybe also the generic sequence, later) may be used in conjunction with other instances embedded inside it. - Parent class inherits all common dunder methods. - Also require calmjs-3.3.1 (even though this was not created at the point of the original creation timestamp of this commit).
- Have the conversion be done in the same manner (API) as the mapping type. - Also note that the type checking (isinstance) is now done using the individually imported asttypes class from the original module, such that the correct subclass hierarchy is applied. - The webpack plugin class now subclass from that.
- Keeping this plugin in place for now.
- Follow the usage patterns of the ConfigMapping and have the webpack version be one of the reserved keys. - Modified how attributes are initialised so that the _setup function can also define the initial default values for the mapping.
- Include the required keys for webpack-4.0.0 to ensure functionality of webpack-2.0.0 is preserved (e.g. no default mode or devtool). - Remove the prototype webpack version custom configuration code. - Remove old template definitions. - Remove some unnecessary configuration serialization matching checks as these are done inside the configuration classes (and that those checks are hard to port given the variation in webpack versions, which are tested separate). - Also a bump to the minimum Node.js version is required, given that the testing through karma requires features only supported by Node.js>6; also that Node.js 4 has been EOL'd. - Also bump calmjs.dev to 2.2.2, as that implements some required fixes to ensure karma actually works with the new custom configuration that is generated by this package.
- This version of karma-webpack may have resolved some issues with working with newer versions of webpack. - Moved 2.6 to 2.7 examples as there were no changes, and this reflects the current version number. - Also include new example data 3.12, 4.0 and 4.16 as there were various semantic changes between all of these, and to increase sample size of supported configurations and outputs.
- While I normally stitch these back in via rebase, the fact that Python 2 is starting to take extra work and these changes highlight that fact.
- This was a legacy from before there was a `which` specifically for getting a binary from node_modules for environments that do not have a node_modules binary directory in PATH. - Given the static assignment for a global instance, this hard static assignment will stop alternative environments from being used if a directory change occured, forcing the default instance to depend on that one directory. - Correct a related test case that was demonstrating the symptom of this issue and maintain this as part of the internal documentation.
- There may be situations that the working directory is in a symlink of some kind and then webpack gets into a situation where it still cannot find itself. This patch address that by calling the version finding routine also in the same manner as the resolution for this.
- Also document exactly why this is done. - Should probably set up a different test case where the Python environment is located inside a subdirectory on the parent of that node_modules...
metatoaster
changed the title
Provide support for webpack~4.16.0
Provide support for webpack>=2.6
Aug 21, 2018
- Not pinning to webpack-4 until calmjs.webpack-2.0.0.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implemented a substantial number of infrastructure to ensure that webpack-4 is supported, while not removing the ability to support most webpack-2 and even webpack-3 usage in conjunction with this integration library.
Notable changes and implementation details includes:
webpack
,karma-webpack
and/orkarma
no longer result in a condition where the karma process will terminate with thesingleRun: true
configured.Task should also be done as part of getting this merged:
2.0.0
release1.2.0
release.