I have a bunch of apps under a single folder with a common dependency.
/app/app1/src/main.js
/app/app2/src/main.js
/app/app3/src/main.js
/common/tools.js
Now several instances of Watchify is running for all of these and if I change anything in any of them, that app will be rebuilt with browserify and reactify. The idea here is to have all the apps only get their own compiled file and not one single huge javascript file containing all the apps. Good so far!
Now the entry point, main.js, of each app starts out something like this
var tools = require('../../../common/tools');
var something = require('./something');
If I make a change in the app specific something.js, that app will be rebuilt and everything works as expected. However, if I update something in tools.js, which have several apps depending on it, that doesn’t happen. In theory, that should trigger a rebuild of all the apps since they all require it, but that doesn’t seem to be the case.
If I change something in tools.js, I have to go to each app and re-save some file in it for it to be rebuilt and get the changes I made.
Is Watchify only looking at subfolders and not parent folders or could there be something else going on here?
I don't think that is how it works.
Watchify will watch the specified folder(s) and trigger a callback when there are some changes.
Changes on other files outside of the watched ones (even when this are required on your app files) will NOT trigger a change, thus wont be detected.
Solution ? Probably redefine what needs to be watched.
Related
We're trying to implement a webpack loader that, between the rest, performs the following:
When loading a file, look for specific dependencies.
Load the filtered dependencies using another loader, with a line that looks like:
loaderContext.loadModule(`${filename}!=!${OTHER_LOADER_PATH}!${filename}`, (err, source) => {...})
(If it matters, the second loader that we use should basically return the exported content of the loaded file).
As far as we understand, the !=! syntax is telling to Webpack to ignore the regular loader rules that should be applied to filename, and instead use only the OTHER_LOADER_PATH to load the file. (see more details here - https://webpack.js.org/api/loaders/#inline-matchresource)
This works well. However, when using this method on a larger codebase, with a complex dependency graph, the compilation gets stuck.
More specifically, it gets stuck AFTER the additional loader is processing the pure dependency filename. It looks like it happens with dependency files that are consumed in multiple places. Meaning, if a file is a dependency to multiple files, and it gets loaded with the OTHER_LOADER_PATH multiple times, the build gets stuck. The OTHER_LOADER_PATH finishes the processing of the file, but the callback for loaderContext.loadModule isn't triggered.
Furthermore, This seems to happen only when using thread-loader (https://github.com/webpack-contrib/thread-loader). Looks like thread-loader is replacing the original loader context with a different, lightweight loader context. We suspect it might be causing the issue. thread-loader does not seem to be maintained properly anymore, and there's no other solution to properly parallelize the compilation process.
We've tried many approaches and hacks, but nothing worked properly. Our questions are:
Is the solution described above (using a separate loader for loading the dependencies) sound legitimate? Is there a different recommended solution?
How can we solve or debug the issue of loadModule not resolving itself?
Is there a replacement to thread-loader that still enables parallelizing the build process? Or, is there a way to use thread-loader so that the build won't hang?
Thank you
What is eslintcache
Why it is always auto generating on the react app.
eslintcache
eslint goes over your code and reports stylistic errors. Usually going over the whole code is unneccessary, because you only changed a few files since the last run. To be able to track which files changed, and which errors occured in the files which were not changed, eslint is writing a cache (into the file you found).
Usually that file is supposed to be in /node_modules/.cache/, so you usually won't notice it. That it resides in your working directory is a bug.
I have a vue.js/Phoenix app. I'm trying to understand how to properly configure the frontend assets. I'm having trouble understanding why my priv/static/js/app.js file keeps updating whenever I Change something in other files. I'm trying to research this behavior but I can't seem to find out any information.
app.html.eex
<body>
<%= render #view_module, #view_template, assigns %>
<script src="<%= static_path(#conn, "/js/app.js") %>"></script>
</body>
My basic question is how to structure a vue.js app? The fact that I change something in asset/src dynamically changes something in static/js/app.js seems really strange. Does anybody have resources or answers on what might be happening here or places I can go to learn more?
In addition to what Pawel said, this behaviour might be intentionally configured. There is the watcher specified in config/dev.exs:
watchers: [
node: ["node_modules/brunch/bin/brunch", "watch", "--stdin",
cd: Path.expand("../assets", __DIR__)]]
That would be used in development mode to allow so-called “hot reload”: one does not need to reload the application when some changes in assets are made, app.js will be rebuilt and reloaded automagically.
There is also assets/brunch-config.js file, where one might specify rules of how the resulting app.js is being produced. By default is just compiles everything found in assets to the single javascript file, but this behaviour might be easily changed (e.g. one might exclude anything from being built into app.js and specify their own rules to provide an access to these excluded files.)
As contrary as this might sound, this is exactly the behaviour Phoenix (with Brunch) provides.
The main idea is to implement your JS functionality in assets/js/app.js, then Brunch (http://brunch.io/) as a build tool will take the content, compile/transpile and output to priv/static/js/app.js.
This means, with default configuration that comes with Phoenix, you can use ES6 in your code in assets/js/app.js, but this will be "translated" to executable form (that's understood by browsers), and located in priv/. priv/static is exposed publicly, and this will be the content available by:
<script src="<%= static_path(#conn, "/js/app.js") %>"></script>
To wrap up.
Code in priv/static is not meant to be changed by code, it gets there automatically by changes you put under your source control in assets/.
If that's any help, you can take a look at one of old blog posts about assets in Phoenix here.
Good luck!
I have been happy using webpack with Vue as of now. It uses a similar, configurable, watcher as the one mentioned by mudasobwa. In Webpack if you touch a file that is in part of the bundle it will recompile the needed files only (which can still be many depending on the dependency graph), probably brunch recompiles all.
I also use Yarn to manage npm, and I always include vuex unless it's really something just basic (although not related to file organisation it does help a lot organising vue on any non-trivial apps). Then
/assets
js
entry point files that I use for webpack output into its own individual bundles/apps
folders to organise these, usually /components-views-related, /store-related, /shared-utilities
css
.scss files, divided so that they can be split into "global" styles and individual styles that then are required in each "entry point". Then I use a "general" scss stylesheet on "all pages" and each page the corresponding css bundle where they're needed.
Then on the templates side, I wrote a small, overly complex, brittle, system to just automate the "bundle" that gets loaded on the template (in the html document head) but you can just load each bundle/s where you need them.
I've written a quite complex brunch-config.js configuration file that modifies these arrays at the start:
paths.watched and,
files.javascripts / stylesheets (the joinTo "filename" => /patterns/).
What I'd like to do is to restart Brunch when it detects a particular change.
I've got a specific file (acts like a flag to set focus on a specific watch-folder) that can be moved around, and in doing so I'd like the above arrays to re-populate different data based on the special file relocation.
Regarding brunch's built-in restart mechanism, I'm not sure how far it goes (ie: when it's reinstalling NPM modules, or when the brunch-config.js file itself is modified). But if that causes a full reload of the brunch-config.js - How can I trigger this restart functionality via NodeJS code executed within the configuration file, more specifically in the "preCompile" hook?
Here's how it looks like so far in action:
This is a complete noob question, but I gotta ask it anyway
I started playing with backbone.js a few days ago and I was really fascinated. As I got over the "ToDo", I started working on a project of my own. Coming from the world of Java, I prefer keeping everything in as many separate files as possible. Therefore, I split my models views, and routers into separate files, into separate folders.
The problem came when I tried to combine those fiels into one single applciation.js file. Again, coming from the Java world, I love when I can automate stuff, and even more, when I can use familiar tools like ant, to setup build processes for my javascript projects.
I got a sample ant build template which concatenates and minifies all the files in an arbitrary order. When it finished, I tried to run my JS app, and not surprisingly, it failed with a bunch of errors. Many of my models and views try to extend each other, others depende on them as components. If they are not defined in a proper order, the app just reaches a point where it is trying to execute extend of an undefined
I know from before that for JavaScript the order is very important, but somehow I was left with the impression that if all the scripts are in one single file, the JS parser will load all the stuff first and then will try to execute whatever is to be executed. Well, my assumption was wrong.
It is possible to list all the files in the specific order I want them, but do I really need to go for such a primitive step? Unfortunately after spending a few hours researching, I couldn't find anything better.
Is it really possible to concatenate JS files, which depend on each other, in an arbitrary order, without them clashing? I guess, the biggest problem is the fact that the extend function is actually being called, rather than each script simply defining and object literal
So, what's the solution?
UPDATE: I just saw that Sproutcore has its own builder. If SC is roughly similar to BB, in the way one creates and extends entities, how does the SC builder work without clashing?
There are many ways to do this, but here's my recipe. I prefix my development files with a number, starting from the one with no dependencies (base "classes", models that will be depended upon from other models, then views using these models, then routers calling those views, etc.).
Then I use uglify-js (available as a node.js library, that you install using npm install uglify-js) to minify all my js in one file (don't know from your question if you use node.js server-side, though). Then I cat *.js | uglifyjs -o min/myfile.min.js. This will send the content of all my .js files (respecting the order of dependencies because of my prefix) to uglify, which will minify it and save it to a single file.
Since I, too, like automation, I have this set up in a Makefile, though I guess it could be done using Ant (not too familiar with it). The relevant part of the Makefile look like this:
TARGET_MIN_FILE = public/js/min/myfile.min.js
JS = $(shell echo public/js/*.js)
public/js/min/myfile.min.js: $(JS)
cat $(JS) | uglifyjs -o $(TARGET_MIN_FILE)
clean:
rm -f $(TARGET_MIN_FILE)
.PHONY: clean
On the other hand, if you go for the asynchronous module definition (AMD) format, you can require() your modules and it will manage for you the dependency loading in the correct order (see Require.js for more info), as mentioned by TheShelfishMeme.
Your "assumption" is only true for var statements and functions of the form function name(a,b) {}. Those two get hoisted to the top of the script (or function block they are in) and are evaluated first.
If your files depend on other files being loaded first, it stands to reason that when you concatenate them they must be in that order in the final file.
Have a look at requirejs. It takes some time to set up but it should help you with your problem.
This article should help with the implementation.