Following PureScript by Example, I'm using pulp for installing packages.
Halogen requires virtual-dom as extra dependency. From the documentation and the example packages, it seems to me that adding it involves a bunch of build tools that I haven't used before (gulp, webpack, bower, etc.). I downloaded the examples and tried to run them with npm install & npm run example but I got unknwon module errors.
So, I'd like to know a minimal viable way to install halogen into a new pulp project (which hopefully doesn't require me to delve into the slew of build tools, or at least not for small projects).
I think you should be able to build it with pulp browserify --to some-file.js - the Browserify option is there for situations like this, where you want to produce a single JS file from a collection of CommonJS modules that may include npm dependencies.
Related
I'm new to Bower, and I'm setting up a dummy project. I have initialised my project and installed jQuery and gulp just to get things started. This is fine, they have been added to my dependencies list in bower.json and are now present in my bower_modules folder. Great so far.
However, I want to install two plugins: main-bower-files and gulp-filter, but bower doesn't seem to have these libs.
When I run bower install --save main-bower-files, I get:
bower ENOTFOUND Package main-bower-files not found
So, it seems my only solution is use npm instead. But surely bower is supposed to be an alternative to npm, right?
Or is the only solution just to npm init as well as bower init at the start of the project, and then run two lists of separate dependencies?
Any help appreciated.
Actually, Bower and NPM have slightly different aims.
In my experience, Bower focuses mainly on frontend packages (jQuery, CreateJS, ...). See it as an alternative of using an external CDN for certain resources. NPM, however, has most of those packages on Bower, and then a large selection of packages for the backend, as well.
You would indeed need to keep two separate dependency lists, if you need packages from both repositories. Using those two managers in tandem is actually not that uncommon.
Be sure to install gulp and its modules through NPM, since they are definitely not frontend resources.
TLDR: Bower = frontend resources that you could have also hosted on a CDN, NPM = everything from frontend to backend and more.
I have an Ionic Project, with all plugins, and libs and I am a little lost on how to manage so many plugins and libs.
Sometimes I install a plugin, test and after that install a couple of other plugins, and so on. After some time, I have so many plugins and I don´t remember what are useful and what are not useful.
So, I would like to create another folder with a fresh version of my project, with only the necessary plugins and libs.
I am now using gulp to minify and uglyfy my code, and I will put all my minified files in this new folder.
So, my questions are:
Is there a simple way to verify what are the plugins and libs really necessary, without need to see it one by one ?
Is there a way to clone all my original project to another one, after I have already cleaned up the original folder ?
Thanks.
when you adding a plugin, you should call
ionic plugin "plugin-name" --save
it will save plugin information to your config.xml and package.json
next time, when your run ionic build, if plugins not install, it will auto install necessary plugins.
about npm module, you should call npm install "package-name" --save-dev to save your develop module, like gulp
in new project, you just copy the package.json and change project name and information, then call npm install, it will install the saved module.
I'm trying to use nuget.exe outside of Visual Studio as part of our build infrastructure. The idea is that the various build tools are fetched by a bootstrapper script that initializes a working copy. The bootstrapper does this by using a file that specifies the required tools and their version.
Broken approach 1 - use manually edited packages.config
At first, it seemed like a good idea to keep a manually edited packages.config file and use nuget restore to install them during bootstrapping. However, this does not work for tools that have dependencies, unless I list every single dependency in the packages.config as well, a much to arduous approach to be feasible, because I found no easy way to recursively find all dependencies of a package.
See also using nuget.exe commandline to install dependency .
Broken approach 2 - use nuget install to update packages.config
The second idea was then to use nuget install to install the packages, and let that command update the packages.config, very similar to the Install-Package cmdlet in the package manager console. But, surprisingly, nuget install does not support this! It either takes a packages.config or a package ID as parameter, but I found no way to update the packages.config with the new package and its dependencies.
This problem can also be found in another (two year old) SO question, see nuget.exe install not updating packages.config (or .csproj)?.
Is there a working (and non-hacky) approach at all?
This must be a problem that many people face when using nuget outside of VS, so what is the best approach in that case?
Of course, I could just parse the packages.config and emit a nuget install for each package, but I really don't want to re-invent the dependency management part of nuget, this is what I'm using nuget for in the first place. So I'm left with the feeling that either an -WithDependencies switch on nuget restore or an -UpdatePackagesConfig switch on nuget install is missing...
Note that there are other SO questions regarding the broken approaches described above. What I'd like to know it what the best approach is to solve the root problem, i.e. manage packages with dependencies outside of VS.
nuget install does not currently make changes to the project file.
nuget install can be used to either restore the NuGet packages listed in a packages.config file or download and extract them.
If you do not need the project being modified then your solution of reading the packages in the packages.config file and calling nuget install seems like a reasonable approach.
If you need the project to be modified then you could look at one of the following:
Ripple - a command line tool that adds extra features to NuGet. It has a ripple install command line which is similar to nuget install but it also updates the project file. It has a lot of other features for supporting build servers so this might be a good fit.
NuGet packages outside of Visual Studio with SharpDevelop - this was an experiment I put together to see whether full NuGet support could be achieved, including PowerShell scripts, from the command line without using Visual Studio. It uses PowerShell and quite a bit of SharpDevelop.
Customise NuGet.exe to do what you need. nuget update, for example, does modify the project file, at least for file references, but will not run PowerShell scripts. So you could take the NuGet.exe source code and extend it.
Of the above only 3) would give you exactly what you need. The other two would require a bit of work to read the packages from the packages.config file or some other list and then install them.
See my answer to Why does the nuget command line tool not follow dependencies?
nuget install My.Package.Id will follow dependencies. However, if you want to install multiple packages, you will need to create a batch file with a separate nuget install command for each package. These are top-level packages. You don't need to "install" the dependencies, as they will get downloaded automatically.
If you ultimately want a packages.config file, I imagine you can generate one by enumerating all the packages that were downloaded. However, you would have to take care not to include multiple versions of the same package.
I believe that how nuget 3 works with project.json files may do what you are looking for. Essentially my understanding is that the unit of dependency becomes the package and not necessarily individual assemblies. From what I recall, the idea is the have only one place to manage these types of package references which the project (IDE/Editor), package manager, and other command line tools can use.
What I don't understand and feel somewhat frustrated about is that it appears that the project.json concept is being canceled. I don't know if plans are to reintroduce it at anytime in the future. In the mean time I keep on hearing updated info on tooling that takes advantage of project.json such as nuget so where you can actually rely on this is something that is unclear to me at this point.
I've created a new foundation project using the foundation new myproject --libsass method.
Its just a simple static index.html (for the purpose of this question).
I've deployed it to a live server now, and I am wondering about the best way to structure this. I have omitted the node_modules & scss directories, and i'm left with the following:
bower_components/
css/
js/
index.html
bowerrc
bower.json
Gruntfile.js
humans.txt
package.json
README.md
bower_components is needed in its current form, unless I shuffle some files around, which is what I intend to do, but I'm checking if there is a better way of doing this, and that I haven't missed some magic terminal command to deploy to production.
As msturdy suggested in the comments, grunt is the way to go here. There are a lot of plugins out there, see a list on the official page.
If you want to have grunt "compile" your project into one specific folder which you can then for example push to a deployment server, you should do several things in grunt:
compile your scss
minify your javascript, that is making the files smaller, see jscompress for a demo of what it is. All your js-files from /bower_components which you include in your project should be in a vendor.js which is loaded first, and then a second js-file should contain your custom js from /js
save everything into a deployment folder.
(optional) automatically deploy to a server.
Take a look at these grunt tutorials for setting up your gruntfile.js, you'll want to have two tasks, one for just quickly compiling your scss, one for the whole deployment process:
grunt is not weird and hard
official tutorial
sitepoint tutorial
They show you how to do certain things and definitely how to write the gruntfile. Plugins you might want to use apart from your current libsass plugin are uglify and any plugin that lets you deploy your code via git, ftp or anything else. You can download all these plugins via npm by adding them to your package.json and doing npm install, refer to their websites for exact usage instruction.
How do I integrate Grunt into Netbeans 7.3, or alternatively allow Netbeans define some external script/program to exec as part of a build.
This is so I can setup Netbeans to compile Less into CSS automatically.
You don't have to change anything in Netbeans.
You should only use the Grunt to compile LESS into CSS, minify your scripts, etc.
Grunt will run in the background and will compile your LESS files into CSS files whenever you make any changes in this files.
Install Node.js (Grunt is running on node.js)
https://nodejs.org/en/download/package-manager/
Install Grunt
http://gruntjs.com/getting-started
On grunt webpage go to plugins subpage and install:
grunt-contrib-watch
grunt-contrib-less
On each plugins subpage you have exact instructions how to set them up.
You can use java to convert from less to css.Or why do you need configuration in NetBeans?You can create a grunt task,call it with terminal,and task will convert what you need.