When looking at bower.json, I assume putting things in devDependencies is the recommended way to deal with things such unit testing dependencies. I'd like to use qunit as my testing framework, but I guess it should apply to other frameworks as well.
The problem I have is that when I put qunit in devDependencies, it doesn't get picked up when building vendor.js. That's expected, but then how do I go with asking brunch to include it? Obviously, I'd prefer to have test-vendor.js where I'd have dependencies + devDependencies, while keeping devDependencies out of vendor.js.
I have this in config.coffee:
exports.config =
# See http://brunch.readthedocs.org/en/latest/config.html for documentation.
files:
javascripts:
joinTo:
'javascripts/app.js': /^app/
'javascripts/vendor.js': /^(bower_components|vendor)/
'test/javascripts/test.js': /^test\/(?!vendor)/
'test/javascripts/test-vendor.js': /^test\/(?=vendor)/
Obviously, the last line wouldn't pick up any bower_component items as-is. Any suggestions here?
I saw this ticket:
https://github.com/paulmillr/read-components/pull/7
but it looks it's still up in the air.
This SOq:
Is it possible to split production and development Bower components?
suggests there's no way to do it from bower side at the moment.
Until this is implemented natively in Brunch, you can hack around it like this, so long as you aren't using Windows:
Add quint and other test dependencies to devDependencies in bower.json. They will now be managed under bower_components.
Add a symlink for each test dependency from your test/ directory to the relevant file under bower_components, eg:
ln -s ../bower_components/qunit/qunit.js test/
The dependencies will then be included in your unit-tests.js.
When brunch supports devDependencies, you can delete the symlinks.
See Ignore directories in brunch production build
You should be able to do something like:
overrides:
production:
conventions:
ignored: /[\/\\]_|bower_components[\/\\]qunit/
And then generate your production build with brunch b -P (brunch build --production)
Related
context: I mostly do rails development along with webpacker. Webpacker puts a package.json at the root of the project.
I was wondering what suggestions people might have for adding aws-cdk into a basic rails application (or any type of web application framework) to make a nice deployment pipeline?
This I've thought about for directory structure:
Adding a .infrastructure folder to the root of the project. This is where all my cdk code would reside. What I don't like about this is during the deploy pipeline I would need to cd into that directoy and run yarn install. Also wouldn't like how I'd have to prefix all my paths with ../ if I need to reference resources outside of the directory (e.g. Dockerfile)
Moving cdk.json to the root of my project. This would solve the path prefix problem but I'd still need todo something along these lines cd .infrastructure && yarn install && cd .. && cdk deploy
Use something like lerna or yarn workspaces? Not sure how much I'd need to configure to webpacker to with those tools.
I tend to over think things way too much...
Am I over complicating this or is a "fullstack engineer" really hard work sometimes? 😅
If you are interested in combining your Infrastructure as Code with your application's deployment strategy you should look into cdk-pipelines. This way, you would just run cdk deploy and all of the build commands would be seperate from the deployment and run as part of the CI/CD build project. I work in .NET but this is how I've structured the folders:
my-repo
my-cool-project
src
MyApi
MyWebApp
cdk
cdk.json
...
Dockerfiles live in 'MyApi', and 'MyWebApp'.
I created a new project with Rails 5.1 and I want to use webpacker to manage my react dependencies. The problem is after installing webpacker it creates a huge 130Mb+ dir node_modules with every possible node_package. This does not make sense as default behavior. How can I configure Webpacker to only keep the packages I'm actually using. I have searched for this issue in every way I could and I did not see any answers that made sense
Install what you need via yarn add, they will be listed in your package.json. Once you run assets:precompile (which will also run webpacker:compile) or just webpacker:compile, the public folder will be populated the compiled assets you are going to need to run the app.
Like Tamer says, node_modules should be in your .gitignore file. In dev, you will see all the node modules due to existing dependencies but that doesn't mean they are going to be used.
In summary, don't worry and rely on yarn.
I don't have much experience with new npm/yarn/webpacker crazyness in Rails 5. So what's the correct way to bundle assets plus their dependencies (like bootstrap 4, for example).
Before it was just a matter of moving entire downloaded js library in /assets and calling it a day.
Let's assume I want to include this datepicker in my Engine: https://github.com/chmln/flatpickr
How do I set it up? Thanks.
Did you get anywhere with this?
It seems there needs to be a solution where the host application can pull dependancies from an engines or gems YARN package.json.
That way it could merge all YARN dependancies together with its own and check if there are no conflicts, if not - Happy days.
A possible workaround is to copy the dependancies over from node_modules into the asset pipeline. This is pretty much the same as what was done previously apart from now rather than looking through each file to find the dependancies and there versions you can just look in package.json.
I have cloned and built the waf script using:
./waf-light configure
Then to build my project (provided by Gomspace) I need to add waf and the eclipse.py to my path. So far I haven't found better than this setenv script:
WAFROOT=~/git/waf/
export PYTHONPATH=$WAFROOT/waflib/extras/:$PYTHONPATH
export PATH=~/git/waf/:$PATH
Called with:
source setenv
This is somehow a pretty ugly solution. Is there a more elegant way to install waf?
You don't install waf. The command you found correctly builds waf: /waf-light configure build Then for each project you create, you put the built waf script into that projects root directory. I can't find a reference, but this is the way in which waf:s primary author Thomas Nagy wants the tool to be used. Projects that repackage waf to make the tool installable aren't "officially sanctioned."
There are advantages and disadvantages with non-installation:
Disadvantages:
You have to add the semi-binary 100kb large waf file to your repository.
Because the file contains binary code, people can have legal objections to distributing it.
Advantages:
It doesn't matter if new versions of waf break the old API.
Users don't need to install waf before compiling the project -- having Python on the system is enough.
Fedora (at least Fedora 22) has a yum package for waf, so you could see that it's possible to do a system install of waf, albeit with a hack.
After you run something like python3 ./waf-light configure build, you'll get a file called waf that's actually a Python script with some binary data at the end. If you put it into /usr/bin and run it as non-root, you'll get an error because it fails to create a directory in /usr/bin. If you run it as root, you'll get the new directory and /usr/bin/waf runs normally.
Here's the trick that I learned from examining the find_lib() function in the waf Python script.
Copy the waf to /usr/bin/waf
As root, run /usr/bin/waf. Notice that it creates a directory. You'll see something like /usr/bin/.waf-2.0.19-b2f63c807a4215294bf6005410c74c18
mv that directory to /usr/lib, dropping the . in the directory name, e.g. mv /usr/bin/.waf-2.0.19-b2f63c807a4215294bf6005410c74c18 /usr/lib/waf-2.0.19-b2f63c807a4215294bf6005410c74c18
If you want to use waf with Python3, repeat Steps 2-3 running the Python script /usr/bin/waf under Python3. Under Python3, the directory names will start with .waf3-/waf3- instead instead of .waf-/waf-.
(Optional) Remove the binary data at the end of /usr/bin/waf.
Now, non-root should be able to just use /usr/bin/waf.
That said, here's something to consider, like what another answer said: I believe waf's author intended waf to be embedded in projects so that each project can use its own version of waf without fear that a project will fail to build when there are newer versions of waf. Thus, the one-global-version use case seems to be not officially supported.
I create a yeoman generator to help myself with front end development.
The problem is, our development environment, framework, plugins are changing so fast...
I have to update dependencies in the package.json in yeoman generator's template directory.
But, usually the package.json in yeoman generator is renamed like _package.json, because of the generator, so I cannot do just npm update.
So, I'll ask you what is the best way to update node modules in _package.json.
Thanks.
For what it's worth, npm update just update dependencies to the latest version matching your package.json dependencies semver ranger. It won't update the file itself.
To know which dependencies are outdated, you can either use npm outdated or a tool like david.
What I usually do with my project is to run one of these tools on a newly generated project. This might not seems ideal, but it's actually the best way to go because:
You ensure your generator is still working (things can break overtime if we're not careful)
You'll be able to test the new versions against your project and see where you need to fix your code so it work with latest release and breaking changes.
Also, npm using semver to set versions, this mean you only need to bump dependencies when a new major version is released. This tends to not happen all that often.
#Simon
Thank you for mention that I misunderstood the behavior of npm update.
Now I do the following step to update _package.json in generator.
create project from the generator yo generator-name
update package.json use npm-check-update.
ensure everything goes ok.
copy package.json into _package.json in generator
But I want to do this like
automatically update package.json in generator
start new project
ensure everything goes ok
I'm not sure this is the best way though...