Hopefully a low-ball conceptual question. I'm having trouble understanding the modules option of r.js build configs. I want to build multiple modules with nested dependencies with one r.js build config.
Say I have the following project structure:
+---build
+---src
+---moduleOne
| +---moduleOne.js
| \---dependecyForModuleOne.js
+---moduleTwo
| +---moduleOne.js
| \---dependecyForModuleTwo.js
|---buildConfig.js
|---devModuleConfig.js
\---prodModuleConfig.js
devModuleConfig and prodModuleConfig are the dev and prod runtime configs, and buildConfig.js is the r.js build config.
Now, I can build moduleOne no problem using this config:
({
"baseUrl": "./",
"name": "moduleOne/moduleOne",
"out": "../build/moduleOneBundle.js",
mainConfigFile: 'devModuleConfig.js',
optimize: 'none'
})
I end up with a bundle in build that I can run after specifying different paths in the build config:
+---build
\---moduleOneBundle.js
I want to build two modules, so specify moduleOne using modules config option:
({
"baseUrl": "./",
modules: [
{
"name": "moduleOne/moduleOne",
"out": "../build/moduleOne.js"
}
],
dir:"../build", // <-- r.js says I need to add this. why?
mainConfigFile: 'devModuleConfig.js',
optimize: 'none'
})
As well as the required dir option, I get all my configs in the build dir, but I did not specify them, and I do not get my bundled module, and I get a text file containing r.js build output. In fact, build ends up looking exactly the same as src:
+---build
+---moduleOne
| +---moduleOne.js
| \---dependecyForModuleOne.js
+---moduleTwo
| +---moduleOne.js
| \---dependecyForModuleTwo.js
|---build.txt
|---buildConfig.js
|---devModuleConfig.js
\---prodModuleConfig.js
How do I configure multiple modules to build using one r.js config? I've read the docs a few times and can't get my head around it.
You can see my project that contains all this here: https://github.com/sennett/r.js-multiple-modules
When specifying modules, r.js includes all files then optimizes ones based on the rules specified in modules. removeCombined: true deletes modules from build that were combined into another module, and then manual deletion of the other files can be used to manually clean up any unwanted build artefacts.
Related
I want to configure the babel options in my Ember app to either ignore the data-stubs folder, or set compact to false so I can silence the following error during builds:
[Babel: my-app > applyPatches][BABEL]
Note: The code generator has deoptimised the styling of dev/my-app/tests/data-stubs/foo.js
as it exceeds the max of 500KB.
Accepted answers on StackOverflow say to configure the .babelrc file with {"compact": false}, but that isn't working with ember-cli builds. Reference Answer:
BABEL Note: The code generator has deoptimised the styling of "app.js" as it exceeds the max of "100KB in Meteor
I made a .babelrc file in the root folder of my ember app and have tried many different configurations:
{
"ignore": ["**/data-stubs/*.js", "tests/data-stubs/*", "*tests/data-stubs/*"], //do not translate our stub files
"compact": false,
"env": {
"development": {
"compact": false
}
}
}
None has any effect and always results in the The code generator has deoptimised the styling error message. I also put a .babelrc file into the data-stubs folder with the same settings as above, and that isn't working either.
This is expected. Ember uses ember-cli-babel which states in documentation:
If you need to customize the way that babel-preset-env configures the plugins that transform your code, you can do it by passing in any of the babel/babel-preset-env options.
Note: .babelrc files are ignored by default.
While you can configure babel and ember-cli-babel in your ember-cli-build.js, I think compact will not work because of this open issue.
However you can specify exclude.
As of now, only the top level options destined for #babel/preset-env will work with ember-cli-babel . Unfortunately compact is not one of those.
In the process of building project with Mix I have the req of placing the result of the build in another dir.
Mix normally places the build artefacts in /project_path/_build.
I cannot write anything to /project_path during the actual build.
Can I change the output dir? Is this something that can be easily adjusted?
Based on this, you can specify a keyword list member build_path to override the default _build directory.
Example:
def project do
[app: :my_app,
version: "0.0.1",
elixir: "~> 1.2",
build_embedded: Mix.env == :prod,
start_permanent: Mix.env == :prod,
build_path: "custom_build_dir",
deps: deps]
end
I currently have the following project structure:
project/
tsconfig.json
webpack.config.js
package.json
node_modules/
...lots of dependencies
typings/
...lots of .d.ts files for the dependencies
src/
...folders for files for my projects
My tsonfig.json looks like:
{
"compilerOptions": {
"module": "commonjs",
"target": "es5",
"noImplicitAny": false,
"outDir": "./js",
"rootDir": "./src",
"sourceMap": true,
"jsx": "react"
},
"exclude": [
"typings/main.d.ts",
"typings/main",
"node_modules"
]
}
This all works very well and I can happily develop my application and run it in a browser.
I would now like to add some unit tests to my project and coming from a Java background my initial instinct is to place the tests in a separate folder:
project/
test/
...all of my test cases
Of course, the files in the test/ folder need to reference the code in my src/ folder. How do I set that up?
Or is it "better" to place the tests inline in the src/ folder and have a separate webpack.config.js file for them?
Really confused about how this works in practice in larger TypeScript projects.
Note: I have seen this but found the answer less than illuminating. It seems that the referenced feature discussion about filesGlob would help me, but I just wonder how people are doing this today?
Now other than rootDir, you can use rootDirs
"rootDirs": ["./scripts", "./src"],
for multiple folders.
Here is the API doc: https://www.typescriptlang.org/docs/handbook/module-resolution.html#virtual-directories-with-rootdirs
I think you are looking for path mapping. With the paths compiler option, you can specify not only a mapping to a single location but to several. This is the example from the documentation:
"compilerOptions": {
"baseUrl": ".",
"paths": {
"*": [
"*",
"generated/*"
]
}
}
If the compiler does not find a module in the expected location, it repeats module resolution in the "generated" subfolder. The baseUrl setting seems redundant but it is mandatory.
Or is it "better" to place the tests inline in the src/ folder and have a separate webpack.config.js file for them?
That is what I do. Do not use the TypeScript compiler as a module bundler (Especially if you are not using modules https://github.com/TypeStrong/atom-typescript/blob/master/docs/out.md). Just let it do the compile and bundle for browser using webpack and use as it is (if using module commonjs) for backend (nodejs).
I've cloned the OpenLayers 3 repo and merged the latest from master. There exists a recently merged pull request that I'm interested in exploring, but I'm not sure how to create a regular old comprehensive, non-minified build.
Does anyone know how to create a non-minified, kitchen sink (everything included) build for OpenLayers?
(similar to ol-debug.js).
You can use the ol-debug.json config to concatenate all sources for the library without any minification.
node tasks/build.js config/ol-debug.json ol-debug.js
Where the ol-debug.json looks like this:
{
"exports": ["*"],
"umd": true
}
The build.js task generates builds of the library given a JSON config files. The custom build tutorial describes how this can be used to create minified profiles of the library. For a debug build, you can simply omit the compile member of the build config. This is described in the task readme:
If the compile object is not provided, the build task will generate a "debug" build of the library without any variable naming or other minification. This is suitable for development or debugging purposes, but should not be used in production.
I'm new to Intern and trying to figure out how to configure it for our project. Our file hierarchy is not exactly the same as the examples in the intern-tutorial or readme for intern on github. I think I have the package locations correctly specified as it does not complain about not finding the test module. It even seems to run the test I have setup but it then tries to run tests on the rest of the modules defined in my package module being targeted. It first tries to load .../dojo/_base/declare.js. So I tried to specify the excludeInstrumentation property value.
I specified it as:
excludeInstrumentation: /^(?:dojo|dijit|dgrid|tests)\//
but it doesn't exclude it. My target module has this in the define:
define([
'dojo/_base/declare',
'dojo/_base/lang',
'dojo/dom-construct',
'dojo/on',
'dojo/query',
...
'dijit/layout/BorderContainer',
'dijit/layout/ContentPane',
'dijit/form/TextBox',
...
'dgrid/OnDemandGrid',
'dgrid/Keyboard',
...
But I get errors:
node node_modules/intern/client.js config=tests/intern
Defaulting to "console" reporter
Error: Failed to load module dojo/_base/declare from
/home/bholm/Projects/src/sandbox/dojo/_base/declare.js
(parent: ev/grids/FilterGrid)
at /home/bholm/Projects/src/sandbox/node_modules/intern/node_modules/dojo/dojo.js:742:12
at fs.js:207:20
at Object.oncomplete (fs.js:107:15)
I should note that the dojo, dijit and dgrid packages are actually located in:
/home/bholm/Projects/src/sandbox/libs/dojo/... (notice the addition of libs in the path).
I forgot to add my loader property in the config file intern.js:
loader: {
//baseUrl: '..',
packages: [
{ name: 'intern', location: 'node_modules/intern' },
{ name: 'ev', location: 'web/libs/ev' }
]
},
Any ideas on why the regex is not excluding?
Do not put the intern package in your loader configuration. Only put application-specific configuration in the loader configuration.
excludeInstrumentation is only to prevent your scripts from being modified with code coverage data when passed through the Intern proxy. It does not change the way the loader works, or stop your AMD dependencies from being requested and loaded normally.
If your application uses 3rd party packages (dojo, dijit, etc.) that are not directly within baseUrl, you need to make sure that they are configured in packages, just like they need to be configured when running the actual application.