I need a Compass hook after compiler compile all SCSS files to CSS in STANDALONE (no Rails) project.
Is there any post-compile hook in compass other than editing "compiler.rb" (which is not good solution, because of gem updates)?
Ok I found it ;)
Compass has this hooks:
on_sprite_saved
on_sprite_generated
on_sprite_removed
on_stylesheet_saved (this is what I was looked for)
on_stylesheet_error
Sad, that on http://compass-style.org/ there is no info about any hook.
The Compass callbacks are documented in the Callbacks section of http://compass-style.org/help/documentation/configuration-reference/#callbacks.
The on_stylesheet_saved hook will fire after a .css file is compiled. You can invoke it by adding the following to the bottom of your config.rb file:
on_stylesheet_saved do |file|
#Do Ruby stuff. Below outputs to command line.
puts ">>>> ZOMG"
end
Related
I have a project written in Typescript, and I'm using node-dev alongside ts-node in my local enviroment for development. I'm using child_process's fork method to instantiate a subprocess, like so:
fork(path.join(__dirname, './worker.ts'));
This works fine, and I can even set breakpoints in VS Code for the worker.
The problem is that when building (transpiling) my project, a MODULE_NOT_FOUND exception is thrown because worker.ts turned into worker.js. Initially, mi idea was to omit the file extension when forking (fork(path.join(__dirname, './worker'));), but if I do so, when running the project with node-dev, it throws a MODULE_NOT_FOUND because it can't resolve the file if the extension is not present.
Is there any workaround for this? Maybe an extra configuration option for node-dev?
I'm on Windows 10 using node v12.22.1
A simple solution I suggest would be to read in the current file type. The compiled files should end with ".js" while the source files end with ".ts". Using the path.extname methode in combination with __filename you can easily extract that file extension and simply concat it to your file name.
fork(path.join(__dirname, './worker' + path.extname(__filename)));
I have Laravel Mix 4.0.13 installed.
npm run watch works great, and running npm run hot it does seem to compile and detect my changes, recompiling.
However, nothing changes in the browser. In the console I see:
[HMR] Waiting for update signal from WDS...
[WDS] Hot Module Replacement enabled.
And after compiling, I get the following message twice, every time I compile:
[WDS] App updated. Recompiling...
I assume there needs to be another message that says reloading or something?
Another strange thing, if I try to refresh the page, it never loads anything from localhost:8080. It just sits there waiting indefinitely. I have to restart npm run hot and then reload the page.
Both JS/Vue and SASS doesn't reload in the browser.
You probably use .version() in your mix file.
Like in the docs, versioning in development is not very useful, so you could;
if (mix.inProduction()) {
mix.version();
}
Docs: https://laravel.com/docs/5.8/mix#versioning-and-cache-busting
It seems there is a problem with mix.version(). After removing .version() from my webpack.mix.js file, everything appears to work.
Also maybe file is in different case, like 'element.vue' or 'Element.vue'
Make sure you include manifest.js in the page
I am trying to learn Node and React and I ran into an interesting problem where - in the import statement like below, I need to explicitly type the file format (.jsx) otherwise, the compiler borks up and complains that it cannot find App.js file.
import App from './App.jsx';
Note - App is a jsx file and saved as App.jsx. I used create-react-app for boilerplate code.
Also, I found some more information on GitHub on the lines of "The distinction between .js and .jsx files was useful before Babel, but it’s not that useful anymore."
https://github.com/facebook/create-react-app/issues/87
So, it looks like a non-issue as long as save it as .js and I have babel to compile ES6.. Thanks everyone!
Here your assumption is incorrect.
If I am right then you are assuming that if your file is .jsx, then you don't need to specify the file extension in the import statement to import .jsx file.
But its the other way round.
If you don't specify the extension of the file then compiler assumes that it is a .js file. So, there is nothing wrong with the behavior that you are seeing.
OR
If you don't want to include extensions in the import statement then just create .js files. Compiler will automatically detect the jsx written inside it. This is the easiest way to fool import statement.
Any javascript react snippets will not show up in a plain .js file only a .jsx file
I suggest that closing the running project on Browser
(ctrl + c / command + c on terminal to finish running project) and do
'yarn start' or 'npm start' again. then it would work!
React sometimes shows errors when you add new files like jsx, js, etc..
and I also had the same problem with you.
(I changed App.js to App.jsx and webppack error was occured).
In these case re-starting project would be the solution!
finally you don't need to specify file extension (like the other answers suggestion).
I'm trying to incorporate JSDoc into my Grunt deployment process. When I run it, I get the following error (expectedly):
>> JAVA_HOME is not set. Jsdoc requires Java to run.
Fatal error: Bad argument
I know that JSDoc is java-based, but I'm hoping to remove Java from the equation wholly. Is there a way to do this with the existing grunt plugin, or another that runs the process in Node only?
I don't want to add Java just for one task. Is this a fool's errand?
There's no way to do this from the current grunt jsdoc plugin. The issue is with the underlying jsdoc utility of course. You can track their progress toward supporting node.js instead of Rhino here:
https://github.com/jsdoc3/jsdoc/issues/93
However, a couple notes about that error you're seeing.
At least on Linux, as long as java is in the path, you can safely ignore that error and it will still generate.
see this question for some other discussion about JAVA_HOME and grunt-jsdoc-plugin
The JSDoc dependency on Java, required by Mozilla Rhino, has been removed in JSDoc 3.3.0. The JSDoc GitHub page states:
Native support for Node.js is available in JSDoc 3.3.0 and later. JSDoc supports Node.js 0.10 and later.
JSDoc v3.3.0 is still in alpha release status (3.3.0-alpha4 was released on Jan 26, 2014), so to install the latest alpha version use:
npm install jsdoc#"<=3.3.0"
I came across the same problem, and built a little Grunt plugin wrapping JSDoc 3.3 (no need for Java, all running in Node):
https://github.com/usrz/javascript-grunt-jsdoc-ng
Now that CoffeeScript supports the new Source Map hotness, I was wondering if I can also use the source maps not just in my browser, but on the command line while developing my nodeJS apps.
I want the JS compiler to give me more useful error traces where the lines actually match with my coffeescript files instead of compiled JS files.
The source-map-support module does this, just install the module and put this at the top of your code:
require('source-map-support').install()
Now with CoffeeScript 1.6.2 it just "works" if you run your app with the coffee command :)
Until coffee-script gets some better support for require(), try this:
https://npmjs.org/package/coffee-script-mapped