We have a Java project with a JavaScript submodule, the structure looks like this:
java-project
|- folder1
|- folder2
|- ...
|- javascript-submodule
|- package.json
|- ...
Is it possible to set up semantic-release to track changes to javascript-submodule only and trigger the npm release of it using javascript-submodule/package.json?
You can use semantic-release in any directory, you just have to make to cd in that directory before running the semantic-release command.
However the concept of semantic-release is to analyze commits pushed since the last release. It seems you have 2 different projects in the same repo (the Java one and the Javascript one) so the commit analysis would be problematic as semantic-release will also trigger releases for commit that make changes only in the Java project.
In addition semantic-release uses Git tags to identify commits associated with a release. So you will end up with tags like v1.0.0, v1.1.0 etc... that are relevant only for the Javascript project and might conflict with the manual releases you do for the Java project.
Probably the best solution in your case would be to use semantic-release to release both project at once:
- Use the #semantic-release/exec plugin release the Java project
- Use the #semantic-release/npm plugin to release the Javascript project with the option pkgRoot
In such configuration both the Java and the Javascript project would be released together with the same version, and the Git tags would apply to both.
Related
We frequently use RMarkdown based packages to create websites with R (bookdown, blogdown, distill...) and use github-pages to serve the html files via the url username.github.io/repo.
In this approach, the ouput (i.e. html / css) files are also version controlled, and are frequently included in commits by mistake (git commit -a). This is annoying since these files clutter the commit and often lead to fictitious files conflicts.
Ideally, the outputfiles would not be version controlled at all, since the binary files (images) additionally bloat the repo. So I'm looking for a solution where:
Git ignores the output files completely but provides an alternative (but comparable1) method to gh-pages to serve them
Git ignores the output files temporally and committing / pushing them to gh-pages is done in a separate, explicit command
1: The method should be command line based and provide a nice URL to access the website
You could have .html, .css etc. ignored in the main and all other branches but the branch, for example, the gh-page branch, where your github-page is built from.
Git does not support different .ignore files in different branches so you would have to set up a bash script that replaces the ignore file each time you checkout a new branch. See here for how to do that: https://gist.github.com/wizioo/c89847c7894ede628071
Maybe not the elegant solution you were hoping for but it should work.
If you have a python installation on your computer, you can use GitHub Pages Import, a tool designed specifically for this purpose.
You need a python installation since it has to be installed with pip, but once it's installed it integrates beautifully with into an R / RMarkdown workflow.
Once it's installed (pip install ghp-import), you can run ghp-import docs (assuming docs is where your RMarkdown outputs are stored).
There are a bunch of practical options that you can use, including -p to additionally push the changes to your remote after the commit.
You need to tell Git to ignore the folder the book gets built into.
So, for example, by default bookdown puts all the built files in a folder called "_book"
Just add the following line to the .gitignore file in your project.
_book
Then you can work on your book and build it and push changes without worrying about the site being updated.
To update the site, you want to create a gh-pages branch that is only used for the hosted content. Do that with these commands from in your book folder:
git checkout --orphan gh-pages
git rm -rf .
# create a hidden file .nojekyll
touch .nojekyll
git add .nojekyll
git commit -m"Initial commit"
git push origin gh-pages
Make sure (once you put your book content in that branch) that GitHub is set to use that branch for hosting, rather than the folder you were using before.
Then, you can switch back to your main branch with the following command:
git checkout master
Next, you will clone your gh-pages branch into your main project:
git clone -b gh-pages https://github.com/yourprojecturl.git book-output
Then, when you have a version of the built book (in the _book folder) ready to use as your live site, use the following commands to copy the content into the book-output folder and push that to the gh-pages branch where the live site is:
cd book-output
git rm -rf *
cp -r ../_book/* ./
git add --all *
git commit -m"Update the book"
git push -q origin gh-pages
You can continue to use this last set of commands whenever you have a version in _book that you're ready to push live.
I'm currently trying to migrate an old ASP.NET WebSite project to Visual Studio 2015. I'd like to use NPM/Gulp to automatically compile LESS files to CSS (this task was done by WebEssentials in VS 2013).
I added a package.json file to the project to load the required components. This creates a node_modules folder in the root of the WebSite project, and this is where my problem starts:
Since WebSite projects don't have a project file, all files (and sub-directories) found in the project root folder, are automatically part of the project. Due to the deeply nested directory structure inside node_modules, this leads to errors because of too long path names.
An easy workaround is to set the hidden attribute on the node_modules folder (but this has to be done manually by each developer).
Is there a way to tell NPM to put the node modules into another directory e.g. one level above the project (..\node_modules) where the solution file is?
Or is it possible to set the hidden attribute on a folder from a gulp-task (which runs when the project is loaded)?
Based on #Rik's answer, I was able to solve the problem:
Instead of adding the package.json and gulpfile.js into the WebSite project, I added them at the solution level (as solution items). This means, that the node_modules folder is now in the solution directory at the same level as the WebSite project(s).
The only other change was to modify the paths in gulpfile.js accordingly.
You might want to check out npm 3.0+. It installs the modules in a maximally flat structure. It should reduce the paths lengths in the module directory.
From the release notes
Flat, flat, flat!
Your dependencies will now be installed maximally flat. Insofar as is
possible, all of your dependencies, and their dependencies, and THEIR
dependencies will be installed in your project's node_modules folder
with no nesting. You'll only see modules nested underneath one another
when two (or more) modules have conflicting dependencies.
#3697 This will hopefully eliminate most cases where windows users ended up with paths that were too long for Explorer and other
standard tools to deal with.
#6912 (#4761 #4037) This also means that your installs will be deduped from the start.
#5827 This deduping even extends to git deps.
#6936 (#5698) Various commands are dedupe aware now.
This has some implications for the behavior of other commands:
npm uninstall removes any dependencies of the module that you specified that aren't required by any other module. Previously, it
would only remove those that happened to be installed under it,
resulting in left over cruft if you'd ever deduped.
npm ls now shows you your dependency tree organized around what requires what, rather than where those modules are on disk.
#6937 npm dedupe now flattens the tree in addition to deduping.
https://github.com/npm/npm/releases/tag/v3.0.0
For upgrading the windows installation check out this package npm-windows-upgrade
Here's what I want to do:
Create a node package that features the following:
gulpfile.js
All gulp plugins, tasks, configs.
Install this node package (referred to as "my-gulp" from here on) within an Angular app (referred to as "myApp" from here on) via package.json dependencies.
gulpfile.js is copied into app root.
All Gulp tasks can be run from app.
We currently have something similar setup with Grunt (although without the Gruntfile.js copy stuff). It works pretty well to have a common setup for each of our apps, but also several custom Bower components. Just have to bring it in as a dependency and it magically works.
The main issue I've run into so far is when I add my-gulp to myApp's dependencies, run the install, my-gulp comes in just fine, however the individual plugins (my-gulp dependencies) aren't seen. They're installed, but running something like gulp default or whatever shows them missing.
I've tried to setup Gulp dependencies (in my-gulp) under "dependencies" as opposed to "devDependencies", yet still not quite working.
Does anyone have any experience doing something like this?
Am I doing something blatantly stupid here?
Any help is awesome!
Thanks, everyone :)
The problem is the way npm handles nested dependencies. When you install your "my-gulp" package, the directory tree looks like this:
| myApp
|-- node_modules
|-- my-gulp
|-- node_modules
|-- gulp_dependency
As you can see, the dependencies of "my-gulp" are buried inside its own node_modules directory. myApp cannot access them.
You could use something like npm-flatten to move those to the top directory. Otherwise you'll be forced to add each dependency to myApp's package.json.
Edit:
As indicated in your gist, you can load the dependencies by path instead of package name. Instead of copying your gulpfile, simply require it from myApp, then load its dependencies with a relative path:
// myApp/gulpfile.js
require('my-gulp/gulpfile.js');
// my-gulp/gulpfile.js
var gulpDep = require('./node_modules/gulp-dependency');
Note: This won't work if you use npm dedupe.
I'm trying to convert a single module project into two modules with a
root aggregate. Feels like a normal thing to do.
So, to simplify I have removed the second project that I added, but I
do something like:
cd myproject
mkdir core
mv * core
and then add a build.sbt in myproject like
lazy val root = project.in( file(".") ).aggregate(core)
lazy val core = project in file("core")
However, trying to build core I get:
[myproject]/core/build.sbt:22: error: not found: value lessSettings
seq(lessSettings:_*)
which is the settings for a plugin added in project/plugins.sbt of the
original project now in
[myproject]/core/project/plugins.sbt
How come this is not picked up? Can't I have plugins living only in
submodules? cd:ing into core submodule and running sbt it works just fine. Do I have
to move my plugins to root/project? Pretty please, it can't be so?
Your plugin.sbt file is ignored because you cannot have a project subfolder in a sub-project of a multi-project build.
In a multi-project build,
The .sbt files of the root project, and all .sbt files of all sub-projects, are all part of a single build definition. The settings defined in a sub-project are just automatically scoped to that project.
Since there is only one build definition, there is only one project to build that build definition, and that is in the project/ folder of the root project. All project/ folders of sub-projects will be ignored.
In your case, moving your plugin.sbt to the build root project folder should make your plugin appear again.
Furthermore, if you only work on the core project, instead of running sbt in core, you can run sbt in the root project and type project core to "move" (actually, scope everything you do) to the core sub-project.
If I install any grunt plugin, it is added to a folder named "node_modules" in the root of my project dir per default.
My question: is it possible to move this whole folder (and therefore all plugins) to another location (but still within my project folder), let's say to "build/node_modules" ?
Of course, I still want to be able to run grunt from anywhere in my project hierarchy after this change.
Nope, that's a feature of the Node.JS core files. In the case you don't know, Node.JS is the platform which Grunt was built.
All require() calls which don't point to an absolute file or start with ./ will try to find modules inside node_modules folders.
You can use symbolic link ln -s /original_node_modules_path/node_modules ./node_modules