I'm trying to get to grips with the babel transpiler. It's docs start by telling you how to install it globally, and then, shortly thereafter tells you you should never do this, and never explains how to run it that way. Well, I believe I wish to run it that way (because the presence of the node_modules directory, or possibly the .babelrc file, cripples brackets, which is the editor I'm currently needing to use).
I can run babel from the global installation easily enough, but it doesn't do anything. The only way I've succeeded in getting it to do any actual translation has been using the local invocation with the .babelrc file, which of course kills my editor (and yes, I actually do have to use that, and I'm not creating a node-based project in any other way, just plain ES6).
Is there some way to use the command line to provide the information that the .babelrc file specifies (and thereby have something other than simply file copying)? Or some other way to get babel to do what I need without physical presence in my source tree?
Related
Does anybody know how to use workbox without getting it from the CDN? I tried this...
add workbox-cli to my dependencies:
"workbox-cli": "^3.6.3"
which gets me all of the following dependencies
$ ls node_modules | grep workbox
workbox-background-sync
workbox-broadcast-cache-update
workbox-build
workbox-cacheable-response
workbox-cache-expiration
workbox-cli
workbox-core
workbox-google-analytics
workbox-navigation-preload
workbox-precaching
workbox-range-requests
workbox-routing
workbox-strategies
workbox-streams
workbox-sw
Then I replaced this line in the examples
importScripts('https://storage.googleapis.com/workbox-cdn/releases/3.6.1/workbox-sw.js');
with this
importScripts('workbox-sw.js');
after copying node_modules/workbox-sw/build/workbox-sw.js to the public folder
But now I realise by looking at the network tab, that that file still gets all the other modules from the cdn
(I thought it would be build with everything inside it.)
Can anybody tell me if there is an npm package somewhere that already has everything inside it? Or should I copy the modules I need from the npm folder, and somehow tie them all together myself? Or do I have to use the webpack plugin? (which I guess will only bundle the modules that I use)
(Update: Workbox v5 makes the process of using a local copy of the Workbox runtime much simpler, and in most cases, it's the default.)
There's one more step that's required. The "Using Local Workbox Files Instead of CDN" has the details:
If you don’t want to use the CDN, it’s easy enough to switch to
Workbox files hosted on your own domain.
The simplest approach is to get the files via workbox-cli's
copyLibraries
command
or from a GitHub Release, and then tell workbox-sw where to find
these files via the modulePathPrefix config option.
If you put the files under /third_party/workbox/, you would use them
like so:
importScripts('/third_party/workbox/workbox-sw.js');
workbox.setConfig({modulePathPrefix: '/third_party/workbox/'});
With this, you’ll use only the local Workbox files.
Is it possible to use environmental variable substitution when including another configuration file?
I would like to have something like that:
include "${HOME}/.foo/credentials.conf"
Configuration documentation mentions locating resources and include substitution but not together.
This works:
include "/home/me/.foo/credentials.conf"
and my HOME is correctly set.
But all attempts to make include "${HOME}/.foo/credentials.conf" so far failed
Background:
I deliberately want to keep credentials and other sensitive data out of our code base but have them available for local dev environments for testing. I am aware of more sophisticated solutions using external storage like hinted here Playframework 2 - Storing your credentials and we use something similar for live and preview environments but these are not suitable for local dev setup.
An alternative is to include credentials file to code base after all but use git ignore to prevent pushing it, but it is fragile solution and risk is someone will eventually push it and compromise credentials.
TBH I'm not even able to include file with absolute path /home/me... anyway approach which will work for you is just using alternative conf file as described in the same doc:
In file /home/me/.foo/credentials.conf you need to include application.conf - Play will fallback it to the file in classpath (this which is under VCS):
include "application.conf"
myCredentials.user="Espinosa"
myCredentials.password="fooBar123"
then run/start your app with this config file locally:
play -Dconfig.file=${HOME}/.foo/credentials.conf ~run
and that's it.
Note: of course it's easier to setup this addition in your IDE (i.e. IntelliJ: Run > Edit configurations) or write a shell script containing this command
If I compile a script for distribution as a standalone exe, is there any way I can store settings within the exe itself, to save having to write to an external file? The main incentive for this is to save having to develop an installation process. I only need to store a few bytes.
Also, can resources such as images be compiled into the exe?
Using alternate data streams opens up a can of worms so i wouldn't go that way. Writing back config data into the exe itself won't work as the file is locked for write access during execution.
What i usually do is to store config data under %A_AppData%\%A_ScriptName%\%A_ScriptName%.ini
When the script starts i use IniRead which also provides a default value if the key isn't found - which is the case the script is executing for the first time.
The complementing IniWrite's in a OnExit subroutine/function will create the ini file if necessary.
This way no installation is needed and the config is stored in the proper, familiar place.
The autohotkey forum has dealt with this question before.
In that case, the user didn't want extra files -- period.
The method was to use the file system to save alternate data.
Unfortunately I can't find the post.
A simpler method is to use fileinstall command.
When the script is compiled, the external file is stored within the exe.
When the script executes the same command as an exe, the file is copied to the same
directory as the running script. It is a simple yet effective 'install'.
With a little testing for the config file, the fileinstall command can be skipped.
Skipping the fileinstall could allow changes to be made to the configuration after 'installation'
I have not tried saving settings within the compiled exe file, but I have included resources. I'm not sure which version of AHK you're using or how you are compiling, but I can right-click my scripts to compile. There's an option to compile with options, where you can include resources in your compiled exe.Compile with options
I'd like to play around with integrating coffeescript into my dev process. But as I see it, I'll have to make a bat file that iterates a set of coffee files and spits out js files. Every time I write a bat file, useful as they may be, I ask myself: is there a better way?
Which makes me wonder: is there an app of some sort for Windows that will watch a directory or a file and spit out one/many js files when a coffee file is saved? I'm thinking of building one but don't want to reinvent the wheel. I looked around and found things that were similar but nothing that elevated it beyond "run this command line" on Windows.
Edit: already marked an answer, but looking at this 10 months later the answer is: grunt. Because it'll do a lot more than just auto-compile your coffeescript and you'll probably need to do more than just that to get your app going.
coffee --watch -o lib -c src
where src is a directory containing your coffee files, and lib is your JavaScript output directory.
See update at bottom of post.
I was hunting for the same thing the other day and came across this: https://github.com/danenania/CoffeePy
It's a simple python script that uses PyV8 to run coffee-script.js.
It doesn't do anything fancy, just watches a folder recursively, and compiles any .coffee files whenever they're changed. It doesn't even have a bare option. These things could be very easily added though!
Edit:
I forked the script and added --bare and --output options.
You can get it here: https://github.com/johtso/CoffeePy
Personally, I prefer using build tools like grunt.js / yeoman or brunch for that purpose.
grunt.js
&
grunt coffee
Mindscape Workbench has a built in compiler/editor for VS 2010. Haven't tried it yet, but it looks like it'd be even better than a watcher/compiler. Scott Hanselman has a post about it here:
http://www.hanselman.com/blog/CoffeeScriptSassAndLESSSupportForVisualStudioAndASPNETWithTheMindscapeWebWorkbench.aspx
I think there is a simplier way just using -w option of coffeescript compiler
coffee -c -w *.coffee
This will compile all coffee files under the folder you are (put more file pathes if needed) each time you change one.
Another possibility: WebStorm 6. They've added a built in file-watcher for a variety of next-gen languages like SASS and Coffescript.
If you want a different way of doing it, this might help:
http://jashkenas.github.com/coffee-script/#scripts
If you include the coffeescript compiler on your page, you can include files with a "text/coffeescript" type and they will get compiled client-side.
Word of warning: Obviously, client-side compilation is not for something serious, but its completely fine for a small project/quick development. It would then be trivial to compile them on the server and change the MIME-type and filename when something a bit quicker is necessary.
CoffeeScript-dotnet does what you want, but it is a command line tool.
Command line tool for compiling CoffeeScript. Includes a file system watcher to automatically recompile CoffeeScripts when they change. Roughly equivalent to the coffee-script node package for linux / mac.
Here is the best way to do it:
Say your work is in "my-project-path" folder.
Go to the parent folder of "my-project-path"
Start a terminal and type coffee -o my-project-path -cw my-project-path
This line will watch and compile anything name as "*.coffee" in "my-project-path" folder, even if it is in "my-project-path/scripts/core" or "my-project-path/test/core".The js file will locate in the save folder as the .coffee file.
I'm interested in Qooxdoo as a possible web development framework. I have downloaded the SDK and installed it in a central location on my PC as I expect to use it on multiple projects. I used the create-application.py script to make a new test application and added all the generated files to my version control system.
I would like to be able to collaborate on this with other developers on other PCs. They are likely to have the SDK installed in a different location. The auto-generated files in Qooxdoo seem to include the SDK path in both config.json and generator.py: if the SDK path moves, the generator.py script stops working. generator.py doesn't seem to be too much of a problem as it looks in config.json for an updated path, but I'm not sure how best to handle config.json.
The only options I've thought of so far are:
Exclude it from the VCS, but there doesn't seem to be a script to regenerate it automatically, so this could be dangerous.
Add it to the VCS but have each developer modify the path line and accept that it might need to be adjusted whenever changes are merged.
Change config.json to be a path and a single 'include' line that points to a second file that contains all the non-SDK-path related information.
Use a relative path to the SDK and keep a separate, closely located copy of the SDK for every project that uses it.
Approach 1 would be ideal if the generation script existed; approach 2 is really nasty; I couldn't get approach 3 to work and approach 4 is a bit messy as it means multiple copies of the SDK littered about the place.
The Android SDK seems to deal with this very well (using approach 1), with the SDK path in its own file with a script that automatically generates that file. As far as I can tell, Qooxdoo puts lots of other important information in config.json and the only way to automatically generate that file is to create a new project.
Is there a better/recommended way to deal with this?
As an alternative to using symlinks, you can override the QOOXDOO_PATH macro on the command line:
./generate.py source -m QOOXDOO_PATH:<local_path_to_qooxdoo>
(Depending on the shell you are using you might have to apply some proper quoting of the -m argument). This way, every programmer can use his locally installed qooxdoo SDK. You can even drop the QOOXDOO_PATH entry from config.json to enforce this.
We work with a symbolic link pointing to the sdk ... config.json contains just the path of the link.