I am preparing a workaround for my problem described in my socketStream/Node.js/Karma question.
I decided that karma is really not required to run Jasmine if you have a socketstream server to run your code anyway.
I include jasmine files through the SocketStream client code libs folder and that works (after editing the TestRunner.html file to make it a SocketStream view). The problem now is that my spec files to run the actual tests only run if I put them in the 'libs' folder.
I'd like to put them in a '/tests/specs' folder but when I do that they are delivered as modules.
Is there any way to mark a folder to behave the same as the 'libs' folder(s) i.e. not pack the content as a module?
There is no easy way. However you can bundle up your tests in a content string and serve it with.
ss.client.assets.send('tests',--content--)
Related
I am using 'animate.css' as a npm package. to use it I specify import 'animate.css' during development. But in production it says to include 'animate.min.css'. How to specify to parceljs to pick the animate.min.css during production build.
or would import animate.css would be able to resolve to right animate.css in development build and animate.min.css in production build. how does the resolver know to pick right file as the main file is specified as animate.css in the package.json
But the there is "Files" property in package.json ...not sure if it can help.
The high-level answer is that parcel automatically minifies and optimizes css files, so you don't need to do anything special to make sure that your production build is as small as possible.
If you want to understand in detail how parcel handles this particular package, read on.
Parcel generally follows node resolution conventions to figure out which files to actually import when you reference a package name.
In this case, the import "animate.css" will tell parcel to go looking in the nearest node_modules folder for a for a subfolder called animate.css. It finds it, and then looks for the package.json file at the root. In this case, the package.json has a main field that points to a file called animate.css (e.g. the un-minified version).
Parcel will use that file as the basis for development and production builds. When you run parcel in development, it leaves this file untouched. When you run parcel build it will process this (unminified) file through cssnano so the build output is minified.
So the interesting fact is that even though there is another file called node_modules/animate/animate.min.css living there, Parcel is able to achieve the desired behavior without touching it. The publishers of animate.css included it for other folks that aren't using a bundler that's as awesome as parcel - you can safely ignore it.
So, I am setting up a new site and my project's folder structure looks like this now.
foo.com/
index.php
assets/
css/
img/
js/
vendor/
I have added vendor/ for js/css libraries that I must install to keep them separate, since I want anyone who installs my project to install those in vendor from package.json - most libraries contain too many files 99% which I don't want to push to production.
Now once the project is finished, I would like to push the code to production with only the necessary js/css files.
This is where the problem comes. For example, if I install bulma css using:
yarn add bulma --modules-folder ./assets/vendor
It will dump all bulma-related files which are almost 70 into /vendor/bulma/ but I will only be needing one or two css files afterwards, since I will compiles the sass file to css as:
sass vendors/bulmna/style.scss assets/css/style.css
So my questions is: I am assuming this is how every developer does it and there are no documentations I can find that suggest how to do it. Is it safe to ignore the /vendor directory? What if I install vue, font-awesome, bootstrap .. how can I only fetch the files I need but not everything in /vendors folder?
Your question is actually quite broad - however, I'll try to list as much as possible.
Lets say you're building a project from scratch and needed to include vuejs, jquery, fontawesome but only need to include a couple of files.
The issue you're hitting here is module dependency with respect to npm modules. (and there are many different tools that you can use to manage versions on your library dependencies as well as ensuring they are included into your project, i.e. package managers).
Ok - now from here, you may say to yourself
but I only need say, one icon from fontawesome in your final build (dist) and I don't want to commit all my modules into source control
Again, this is where you omit node_modules and other dependent libraries from source control (i.e. include node_modules your .gitignore)
To reiterate
You can install the required library,
add node_modules to .gitignore ,
bundle those libraries into a vendor single file to be consumed by your users (can be via browserify/webpack/rollup/gulp/grunt/yarn etc).
generate bundle within npm script
Now you may ask further -
Why would I use any of those tools? - they're distracting me from simply copy/pasting vendor libaries into my source control.
Build tools were created to
streamline the developer pipeline so that you DONT have to copy/paste vendor libaries into a vendor folder.
ensures that all files are bundled to the client automatically
allows you to keep track/restrict library version updates/ when required via package.json
allows you to add other build steps (such as minification, md5hash versioning, compression, code splitting, asset management to name a few).
Now lets break down the original question here:
How to ensure other developers get everything they need when cloning the repository
how do I ensure I can provide only the necessary files to the end user (if I only use specific parts of vendor libaries?)
1. How to ensure developers get what they need
Again, to reiterate above, adding devDependancies and .gitignoring allows you to only add the necessary files to your project.
2. How can I ensure clients get what they need without bloating request files?
This is where build tools such as webpack, browserify, gulp, grunt, rollup, attempt to achieve. This is because with some libraries that exceed in file size of 200kb minified, you may need to separate these files into different client requests (and as such, not demand the user to request one large file, which was symtomatic of browserify projects).
The second technique you will need to be aware of, is with specific libraries, you can use import mdn link where you can require one function/class from a dependant library (which further reduces file size).
Another technique is using less import statements (which can extract less functions/styles similar to above, but this isn't currently supported in SCSS). for SCSS, you're basically left with copy/pasting the necessary styles into your base scss and that'll save you space as well.
EDIT
How to create a bundle from npm install libaries
From the comments you've mentioned above (about not wanting to include a tool into your workflow, there's no point outlining any one particular strategy - you can find answers/tutorials online about how to setup gulp/browserify/webpack for your particular needs).
However, As you are currently using yarn - I'll go into details about that.
Firstly, yarn is a package manager (like npm). All it does with the --modules-folder is install the package into the specified folder, that's all. So we don't really care about that (since it's doing the same thing as npm). (i.e. your vendor folder is the same as node_modules in many respects).
We could use
webpack
gulp
grunt
rollup
browserify
brunch
(All build tools that essentially allow you to bundle all those packages into a single entry point to be packaged to the client).
I won't go into how, because that is a process you can find online, and from the above comments, I can tell you don't particularly care either.
What you are looking for is a zero-config javascript build tool. (Extremely out of the scope of your original question, and i'll only answer that in a separate Q&A).
I'd try Googling on "tree shaking CSS" to see if that gives you something.
Maybe something like: https://github.com/jacobp100/es-css-modules
Rollup plugin may be useful. It works for js, with postcss, the link says it works with css also.
https://code.lengstorf.com/learn-rollup-css
Have a look at Pancake. It has been built specifically for the purpose of moving only those files out of the node_modules folder that you need. I wrote an article about it here: https://medium.com/dailyjs/npm-and-the-front-end-950c79fc22ce
(probably not an answer but a good tip)
PS: I am the author of both, the article and the tool so with clear bias :)
recently I added somethings into my composer.json file and did a "composer dump autoload". All work fine on development side.
When I put my updates in production, I had this error :
[2016-02-17 08:17:47] local.ERROR: exception
'Symfony\Component\Debug\Exception\FatalErrorException' with message
'Call to undefined function App\Http\Controllers\f_array_classe()' in
/home/dominiquir/ecole/app/Http/Controllers/MatieresEnseigneesController.php:67
when I put my app in production, I put only the "app" folder. But certainly when this file is modified , I must also put in production some other files, but which ones ?
An application which uses Composer has to put online
All files needed to run the application itself - you should know the location of the files because I suppose you created them
all files in the vendor folder.
If you don't know exactly point 1, the globally correct answer is: Your entire project folder after you ran composer install.
To optimize upload times, you should omit the development dependencies: Run composer install --no-dev to remove anything that is not being used for running the application. Development dependencies usually includes test frameworks like PHPUnit or any libraries that are only being used to help developing, like some command line interfaces for the framework being used etc. If your composer.json has entries under require-dev, that's what gets omitted.
The next step to reduce upload size would be to not upload anything of the application itself that is not relevant, like it's tests. But this depends entirely on how you constructed the application.
I would recommend to write a script that does all the preparations to create an optimized upload. It can be a simple shell script that creates a new, empty folder, then copies all needed files and folders into it, then runs composer install --no-dev there, and maybe then again deletes files from the dependency packages that are not needed (like test folders).
You may also run optimizing software for images, CSS and Javascript then. Most of them can be compressed in size without any loss of quality or function.
In the end you get a folder full of files you know have to go online. Just upload the whole folder. Done.
More optimization would be to try using rsync, which will compare the files already present at the target with the ones at the source, and only transfer the necessary minimum, but this requires SSH access of some kind, not just FTP.
So I have this:
/projectA/index.html
And for the sake only for testing I want to have this in index.html
<script src="../projectB/somefile.foo"></script>
Of course, when I run visual studio, my foo file cannot be found because it is above the project "root".
Is there any way to allow IIS to gain access to projectB?
I am using TypeScript with Visual Studio 2013.
Note: I did google this, but I find asp stuff. As far as I am aware, this is not relevant to me?
Thanks!
The browser is trying to access the file at ../projectB/somefile.foo relative to where the current page is. Ask yourself this question, if you were using a web browser, how would you navigate to ../projectB/somefile.foo?
I'm going to make a bit of an assumption and guess that index.html is at a url that looks something like this:
http://localhost:55685/index.html
Now, as you pointed out, it doesn't really make sense to go up a directory using ../ when you are already in the root directory.
You have two options I can think of right now. One is that in the project's properties, on the Web tab you can configure a Project Url for projectB. For example http://localhost:55685/projectB. Then in your app do this:
<script src="http://localhost:55685/projectB/somefile.foo"></script>
You'll have to do some additional configuration if you ever deploy your application, but it's a solution that works if you just need it for development.
Another option is to copy the script files from projectB into projectA. I would recommend this, especially if projectB isn't going to be deployed somewhere. If you are trying to access some TypeScript files, you can use a method similar to what is outlined in this other answer. Otherwise, just make a build event that runs a script to copy all your script files into projectA. After that, reference the script files you need at the location you copied them to in projectA.
I am writing a small application at the moment and am trying to organise my build output to be a little closer to the finished product. The application is made up of a number of different projects. There is a core library that contains most of the functionality, a GUI app and a command line app that both reference the Core Dll, and a number of Plugin Dlls that are loaded at runtime and implement different data sources, these all reference core.dll, these also may include some other third party dlls. There are also a number of peripheral files such as a readme. And finally the core.dll and the datasource plugins are unit tested.
I would like to configure my build so that everything is output into directories as I would expect it to be when installed. I want debug and release builds to be built into different directories but otherwise have the same directory structure. I only want tests to be built for debug builds, and want them to be runnable, but seperated (I guess all test dlls would get output into a seperate directory). Here is how I imagine the structure will be.
Code/
solutions etc here
Debug/
Project.Core.dll
Project.Gui.exe
Project.Cli.exe
readme.txt
lib/
ThirdParty1.dll
ThirdParty2.dll
DataSource/
DataSource1.dll
DataSource2.dll
Tests/
Project.Core.Tests.dll
DataSource1.Tests.dll
Release/
same as Debug but without tests.
Is there any way of getting a solution to build like this? I'm beginning to think it will be difficult to build the plugins and the app all from one solution, and probably not even wise, but as they will all be distributed together it would be nice. I am open to using Nant or another build tool if that will make it simpler.
It is possible. Just modify OutputPath tag manually in each .csproj in both Debug and Release file to something like this
<OutputPath>..\$(Configuration)\any_subdirs</OutputPath>
You can disable tests building for Release using Configuration manager.
Modifying each project every time you create a new one is annoying.
Here's the solution:
Locate the real vs project, it'll be somewhere under ("%programfiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplates*")
Copy it locally somewhere.
Extract it.
Edit the contents making changes that better suit your project layout style. Make sure you update the project name, the name is what you see when looking for the project in the new project dialogue box. It's xml tag is Name, you'll find it in the {something}.vstemplate file.
Compress the content again. (Note: the contents must NOT be in a sub folder, so /* and NOT /{somefolder}/*).
Place your custom project under ("%USERPROFILE%\Documents\Visual Studio 2010\Templates\ProjectTemplates*").
Add a new project is Visual Studio, selecting your custom one, and enjoy!