Hi the first thing I hit in migrating is the difference in the way "paths" work. I had a reference to
paths: { "myLib:*" : "path/to/mylib" }
and then in map: { angular: "myLib:/angular/angular }
But this seems to be gone. How can I do it now in the latest system.js?
The way to do this is to run your system.js 0.19 with warnings: true. Then it gives you good info.
'myLib/': 'path/to/myLib/'
It is much simpler now, you just end in a trailing slash on the path and use myLib like a folder in your map paths, no semi colon.
Related
I'm trying to gently introduce scalafmt to a large existing codebase and I want it to make virtually no changes except for a handful of noncontroversial settings the whole team can agree on.
With some settings like maxColumn I can override the default of 80 to something absurd like 5000 to have no changes. But with other settings I have to make choices that will modify the existing code like with continuationIndent.callSite. The setting requires a number which would aggressively introduce changes on the first run on our codebase.
Is there anything I can do in my scalafmt config to preserve all my code except for a few specific settings?
EDIT: I will also accept suggestions of other tools that solve the same issue.
Consider project.includeFilters:
Configure which source files should be formatted in this project.
# manually include files to format.
project.includeFilters = [
regex1
regex2
]
For example, say we have project structure with foo, bar, baz, etc. packages like so
someProject/src/main/scala/com/example/foo/*.scala
someProject/src/main/scala/com/example/bar/*.scala
someProject/src/main/scala/com/example/baz/qux/*.scala
...
Then the following .scalafmt.conf
project.includeFilters = [
"foo/.*"
]
continuationIndent.callSite = 2
...
will format only files in foo package. Now we can proceed to gradually introduce formatting to the codebase package-by-package
project.includeFilters = [
"foo/.*"
"bar/.*"
]
continuationIndent.callSite = 2
...
or even file-by-file
project.includeFilters = [
"foo/FooA\.scala"
"foo/FooB\.scala"
]
continuationIndent.callSite = 2
...
I want to use class property and private fields in my sapper project. Apparently they have to be preprocessed by babel right now.
I tried to add the corresponding babel plugins to rollup.config.js, only to realize a few things.
the babel rollup plugin is only used in legacy mode.
the server part doesn't use babel at all.
I tried to add the babel rollup plugin to the end of server plugins like this,
babel({
extensions: ['.js', '.mjs', '.html', '.svelte'],
runtimeHelpers: true,
exclude: ['node_modules/#babel/**'],
plugins: [
'#babel/plugin-proposal-class-properties',
'#babel/plugin-proposal-private-methods',
],
}),
But it doesn't seem to take effect at all.
I also added it to the client plugins (before the legacy entry), but it complained about I needed to add #babel/plugin-syntax-dynamic-import, so looks like babel has to recognize the whole syntax in order to preprocess, and I don't really want to compile dynamic import for modern browsers.
How do I enable the use of esnext syntax in sapper?
You would need to preprocess the contents of <script>, using the preprocess option in rollup-plugin-svelte:
plugins: [
svelte({
// ...
preprocess: {
script: ({ content }) => {
return transformWithBabel(content);
}
},
// ...
})
]
In an ideal world we'd have a ready-made preprocessor plugin for doing this; as it is, the transformWithBabel function is left as an exercise to the reader for now. Essentially it would involve import * as babel from '#babel/core' and using the Babel API directly, which I guarantee will be lots of fun.
Note that #babel/plugin-syntax-dynamic-import doesn't compile dynamic import, it only allows Babel to parse it. Without it, Babel can't generate a valid AST from the code inside <script>.
TL;DR: Is there a way how to specify the order in which the Babel plugins are supposed to be run? How does Babel determine this order? Is there any spec how this works apart from diving into Babel sources?
I'm developing my own Babel plugin. I noticed, that when I run it, my plugin is run before other es2015 plugins. For example having code such as:
const a = () => 1
and visitor such as:
visitor: {
ArrowFunctionExpression(path) {
console.log('ArrowFunction')
},
FunctionExpression(path) {
console.log('Function')
},
}
my plugin observes ArrowFunction (and not Function). I played with the order in which the plugins are listed in Babel configuration, but that didn't change anything:
plugins: ['path_to_myplugin', 'transform-es2015-arrow-functions'],
plugins: ['transform-es2015-arrow-functions', 'path_to_myplugin'],
OTOH, this looks like the order DOES somehow matter:
https://phabricator.babeljs.io/T6719
---- EDIT ----
I found out that if I write my visitor as follows:
ArrowFunctionExpression: {
enter(path) {
console.log('ArrowFunction')
}
},
FunctionExpression: {
exit(path) {
console.log('Function')
}
},
both functions are called. So it looks like the order of execution is: myplugin_enter -> other_plugin -> myplugin_exit. In other words, myplugin seems to be before other_plugin in some internal pipeline. The main question however stays the same - the order of plugins in the pipeline should be determined & configurable somehow.
The order of plugins is based on the order of things in your .babelrc with plugins running before presets, and each group running later plugins/presets before earlier ones.
The key thing though is that the ordering is per AST Node. Each plugin does not do a full traversal, Babel does a single traversal running all plugins in parallel, with each node processed one at a time running each handler for each plugin.
Basically, what #loganfsmyth wrote is correct; there is (probably) no more magic in plugin ordering itself.
As for the my problem specifically, my confusion was caused by how arrow function transformation works. Even if the babel-plugin-transform-es2015-arrow-functions plugin mangles the code sooner than my plugin, it does not remove the original arrow-function ast node from the ast, so even the later plugin sees it.
Learning: when dealing with Babel, don't underestimate the amount of debug print statements needed to understand what's happening.
I am working on a project which incorporates C code, as well as (MASM-like) assembly. I want to be able to compile it on Linux, as well as Windows, thus I am using a third-party assembler (jwasm) as follows:
QMAKE_PRE_LINK += jwasm -coff -Fo$$assembly_obj $$PWD/assembly.asm
(here, assembly_obj holds the directory I want jwasm to save the output. Oh, by the way: when using jwasm it is critical to first specify all the parameters, and only at the end the input files, otherwise it will ignore the parameters)
To make it easier for other people to compile the project, I would like to be able to check if jwasm is in their path, and if not, emit an error() telling them how to fix this. However, I am not sure if this is even possible using qmake. I have tried:
exists("jwasm") { # Always false
message("jwasm found!")
}
as well as:
packagesExist(jwasm) { # Always true
message("jwasm found!")
}
I have looked around in the qmake docs, but couldn't find any other alternatives...
I want to implement RequireJS in a very large single page application that uses CoffeeScript and Grunt. We have separate files for different modules (services, Backbone, etc.).
Implementing RequireJS is very straightforward - my main problem is with the size of the application and CoffeeScript's whitespace sensitivity. We need to be able to continuously develop new features while implementing RJS. The reason we cannot do this is because we would have to wrap all files in define calls, and re-tab files. When you try to rebase this code, massive merge conflicts arise due to the tabbing. No one has the time to solve all those problems, as new features and bugfixes may have been introduced pre-RJS.
I've research a few possible solutions:
Stop development and re-tab everything. This sucks because development is stopped until files are tabbed and the code actually works with RJS.
Use CommonJS pattern, and use RJS CommonJS converter pre-RJS optimize. Seems hacky.
Use CoffeeScript backtick functionality to wrap CoffeeScript classes in a standard JavaScript module pattern. Next pass dependencies to the "module" wrapper for the CoffeeScript class then initialize the "module" within the RJS call in the file.
Edit:
Thanks for the tip on the vertical structure & introducing me to passing function arguments that way (comma-less). Our projects are very similarly in structure (except grunt-contrib-coffeee does the linting, unfortunately, at the moment), and I am also building a custom watch task to compile single files (vs. glob patterns).
Consider this very basic example:
view.coffee:
class View
template: Helper.template
constructor: (#options) ->
render: (meters) ->
$('body').html #template #options
The normal process would be to do something like the following with RJS:
define [
'jQuery'
'Helper'
], (
$
Helper
) ->
class View
template: Helper.template 'base_view'
constructor: (#options) ->
render: (meters) ->
$('body').html #template #options
Notice how the entire class has been re-tabbed. Git would hate this if any one of our developers came along and modified the View class, while I was trying to implement require in parallel.
The backtick idea won't work, I can't get around the global problem there:
`var exports = function($, Helper) {
class View
template: Helper.template
constructor: (#options) ->
render: (meters) ->
$('body').html #template #options
return View }(jQuery, Helper)`
define [
'jQuery'
'Helper'
], (
$
Helper
) ->
return exports($, Helper)
I think my best bet is merging all of the applications features together and then pausing for a moment to re-tab every file the necessary two spaces, all in one commit. CoffeeScript doesn't seem to care where the indentation begins (column 0 vs column 2) as long as the rest of the file follows that pattern. We should be able to slide in RJS and implement it progressively in this way, preventing unsolvable merge conflicts.
What we do in our projects:
we use grunt-contrib-coffee and grunt-coffeelint to compile and validate coffee files. With this plugin, you can validate the coffeescript code while developing. You can use a json file which contains validation settings. This makes sure all developers use the same settings.
e.g:
{
"no_tabs" : {
"level" : "error"
},
"no_trailing_whitespace" : {
"level" : "error"
},
"max_line_length" : {
"value": 200,
"level" : "error"
},
...
minimize the chance of merge conflicts in requirejs dependecies by defining each dependency on a separate line.
e.g.
define [
'dep1'
'dep2'
'dep3'
], (
dep1
dep2
dep3
) ->
console.log "Hello"
instead of
define ['dep1', 'dep2','dep3'], (dep1, dep2, dep3) ->
console.log "Hello"
Only commit coffeescript files to source control. Generated javascript files (minified via grunt-contrib-requirejs) we don't commit (only when creating a production version).
we use a custom watch task to watch changed coffeescript files (among other files). Via growl the developer is notified when compilation or validation failed.