I have an UglifyJS file watcher set up in IntelliJ IDEA, and it works great while I'm editing -- I modify the source js, the minified version gets created next to it automatically.
However, when I run an Ant build, and it copies the minified versions into the build working dir, the watcher "helpfully" creates doubly minified versions of them (*.min.min.js) in the build working dir, not ok.
I've set the Scope of the watcher to the 'src' module, but apparently that doesn't do what you'd think it would, because the doubles get created when Ant copies files into the 'build' module. Happens when I use IDEA to manually copy a single file from src to build too.
I don't see how to set this up to include *.js but exclude *.min.js, which is really the right thing. (Seems so sensible that Uglify should have it built in, but far as I can see it doesn't.)
Other than getting rid of the watcher and scripting the build do the minification, or copying only the original js versions and letting the watcher (re)create the minified ones, what's the best way to go here?
Got this working, thanks to a helpful commenter on the IDEA forum. The key is setting up a custom Scope, which I tried to do before but failed.
Pattern I ended up with was this, for anyone with similar needs:
file[src]:*.js&&!file:*min.js*
Making the 'src' module current then opening the dlg and selecting it from the dropdown in the main watcher config window apparently doesn't actually filter by that module. Clicking the ... btn, then choosing it from the dlg that opens does, plus I added an explicit filename pattern to exclude already minified files too.
Works great now, far as I've tested (both a minimal Ant test and manually copying a file to 'build' in IDEA).
This is an old question, and perhaps the Watchers didn't have this functionality at the time.
Using JetBrains 'macro' codes makes the 'min.min.min.js' problem go away.
$FileNameWithoutAllExtensions$.js -m --source-map -o $ContentRoot$\prod\js\$FileNameWithoutAllExtensions$.min.js
I always set 'Scope' to 'Current File', too; why run uglify on files that haven't been altered? (I'm assuming that any 3rd party JS libraries are already minified).
Related
I'm a newbie to both IntelliJ and Aurelia. I did my last web project almost a decade ago, and I find myself a bit lost between all those new libraries. That said, my question is probably of rather trivial nature:
I've downloaded the Aurelia skeleton project [1], imported the sources into a new node js project in IntelliJ and started index.html. Voila. Browser opens, shows the site.
Then I changed something (added a new route to src/app.js).
I hit the run button to show index.html again: No changes. Hm?
I rebuild the project in IntelliJ, and retried. Still my changes aren't shown.
I run gulp watch on the command line, open the browser, and my changes are shown.
So, I'm asking two things: What needs to be done to really refresh the build within IntelliJ?
And secondly, when did it become a sport to create inter-depending Javascript libraries with blurry names? Just kidding... (though I'm not laughing)
[1] https://github.com/aurelia/skeleton-navigation/blob/master/skeleton-esnext/src/child-router.js
I found it out myself. You need to put 'gulp build' to the pre-launch list of the run configuration. This is because the sources get transpiled and copied to the dist directory, from where the server is actually running.
Just building the sources from IntelliJ isn't enough.
Project rebuild start automatically after any files was changed in project directory. You do not need to build it from IDE-- only save your changes and wait a few seconds to refresh.
Of cause it will work only when you run project build with watch statement like gulp watch (e.g. run gulp watch and your project will rebuild automatically).
But if there were some errors in code -- gulp process will stop and you must restart it again. I recommend you change IDE's settings to disable automatically saving to files and use <CTRL+S> buttons to save data manually.
So here's a question. I'm new to Sylius, and am working on some simple CSS updates. I have a local copy of Sylius running with the built-in webserver: server:run. I also have a development server on Digital Ocean, which runs an (almost) identical copy of Sylius, aside from the configs of course.
Something strange is happening with my CSS update, however. I made a change to .navbar-brand within web/assets/compiled/backend_backend_4.css.
This change showed up immediately on my local. On the development server, however, when pulling down the change (git), and verifying that it now exists in that file, the change doesn't seem to propegate. It's effects aren't shown, inspecting the stylesheet doesn't show them, and furthermore viewing the css file sourcecode directly in the browser does not show the change. But on the filesystem it's definitely there.
I've tried clearing the cache, to no avail.
I also checked the assetic value in both config_dev.yml files, and verified they are both set to use_controller: true
Even still, I tried dumping assetic, to no avail.
So I'm wondering what's going on. Additionally, I realize that I probably shouldn't edit CSS files within a folder called 'compiled'. I'm sure there's a way to do that using a compiler, but I'm not yet familiar with the process and am just making minor changes and learning about caching so far.
Yes you are right you shouldn't be editing the compiled files.
You should edit the source files, then run gulp
or on my system i have to explicitly run npm run gulp
I've documented the solution that worked for me here. It didn't involve Gulp at all, but instead uses Assetic:
Assets need to be installed as hard copies first (I'm not quite sure
what this does exactly, but it seems like an important step because
it copies a lot of assets to places. Documentation was unhelpful but
it was suggested on Stack Overflow somewhere.):
app/console assets:install web
Assets should be edited in web/bundles/[bundle-here]/css or js. This
is frequently within syliusweb if it has to do with page styles /
layouts.
Hint: These assets are referred to in files such as
src/Sylius/Bundle/Resources/views/Backend/layout.html.twig (see the
opening:
(% stylesheets
tag, or search universally for this tag).
Within this tag, you'll see that stylesheets have an output to the compiled folder, but also list the
bundles where they pull their original css from. You should edit one of the source css files, if you'd like your changes to end up in the destination css.
After editing assets, dump assetic:
php app/console assetic:dump
Note - it is also possible to set an assetic watcher on these assets
(google to find out how, think it's a -w flag somewhere), but this is
said to only work in development mode, as it should.
After dumping assetic, the assets from the source bundles compile into their assets/compiled versions, usually combining multiple stylesheets. You should now see your asset refresh!
I'm developing a JavaScript/React application in Intellij Idea and I'm using webpack-dev-server to incrementally build my files. That means that the dev server is watching the files and if a file gets changes, webpack rebuilds it. Pretty standard scenario.
Unfortunately, webpack sometimes decides to ignore certain files. I can change them all I want but webpack does nothing. I have not been able to determine any pattern on which files get ignored. It's arbitrary. Sometimes I just create a new file and webpack ignores it.
What is interesting though is that it only happens when I perform the save using Intellij Idea. If I open the file in another editor (for example vim) and save it, the file gets correctly rebuilt. Actually, simple touch file.js is enough to trigger rebuilding.
I guess there is something wrong in how Intellij Idea saves files. Any ideas?
This is due to an IDE feature known as "safe write". When enabled, the IDE will write the changes to a temporary file over the real one. This means webpack's file watching mechanism cannot pick up the changes. Disable this feature to fix the problem. Reference.
For me this did not work, I'm posting this in case anyone has the same scenario. After each save, webpack watch script builds the new bundles and I'm reloading all files from disk (CTRL + ALT + Y). Only after that the changes are visible.
There is an open issue "Background" changes by external tool not being picked up until VFS refresh happens regarding this behavior: file is saved but one has to reload all from disk in order to see the changes (for example in the browser).
I'm using IntelliJ with Gulp (with the babel and sourecemap plugins) to help me transpile my source ES6 to ES5. What is the best way to mark these generated files?
They are being sent into a seperate dist folder but I want them to behave in the following way:
I don't want them to show up in usage/code search
I want their changes to be detected by the integrated source control
I have tagged them as excluded but I read in IntelliJ's docs that this will prevent the folder from being watched for changes. Anyone have a good way of doing this?
Excluding the dist folder via Mark directory as/Excluded is the right way to go: files in excluded folders are not indexed/show up in usage/code search, but they can be version controlled, so both your requirements are fulfilled.
I started using sass scss stylesheets. These generate *.css files from *.scss files. My question is, which files do you check into version control? Right now I check in both main.scss and the generated main.css. I wonder though if there is a way to just check in the *.scss file and to ensure that the *.css files get generated on deployment.
I prefer to check them in. We deploy to our staging and production environments from git and I prefer not to rely on yet another tool/compilation when deploying to production. This way, its absolutely clear what is being pushed out.
In general, you usually don't need to check generated files into source control. As long as your code generation works consistently, and you use it consistently to update your target .css files, I don't think you would need to put them in source control.
That said, the suggestion to not put generated files into source control is usually intended more for binary files (i.e. libs or executables generated from a build). The main reason for this is that binary files cannot be easily diffed/merged, so if multiple people try to checkin changes to the same binary, you may end up with merging issues that cannot be easily resolved. Since you're dealing with plain text css files, I don't think it's that big of a deal to just put them in source control too, just so you have a backup of the actual target file.
I like to borrow from the conventions used by server side developers when handling compiled front-end code like sass. I keep all of my source separate from compiled code. Here's how I set it up:
Put your source in a src directory, under main/language-name, in this case:
/path-to-my-app/src/main/sass/my-syntactically-awesome-file.scss
Then put tests in an identical test directory (you shouldn't need any tests for sass, though:
/path-to-my-app/src/test/sass/my-syntactically-awesome-test.whatever
Then put your compiled code in a publish-ready directory, like so:
/path-to-my-app/publish/css/my-syntactically-awesome-file.css
Then commit the whole shebang (!)
You can make sure you are always putting your css in the right place like so:
$ cd /path-to-my-app
$ sass --watch src/main/sass/*.scss:publish/css/
Now you're a mother effing programmer, baby!