i generated the scaffold of a famo.us project with Yeoman (yo famous)
i set up i small working project
i tried to launch it with 'grunt serve' command
it all works but no image is loaded because the folder content/images is not loaded
how can i include it?
thanks
I'm Myles the author of the Famous-Generator. The images in '/content/images/' should be able to be loaded as an absolute or relative path... although I have just updated the generated 'main.js' to use an absolute path for the sake of being explicit.
Remember that when you famous code is run it will be running inside of index.html, and therefore have the same "relative path" for included assets. As well, since you are serving via a development server, you are able to reference anything with absolute paths relative to the root directory of the project.
You should not have to touch requireConfig at all to be honest. It is only used to add vendor code installed in 'lib' to your path within require so you can reference modules by name rather than path. 'underscore' rather than '../lib/underscore'. This becomes nice as you begin to nest folders and don't want to have to manage relative paths. This also makes your code a lot more portable!
A nice sidebar, you should install all vendor code with 'bower install --save $LIB_NAME'. This will save the library / version to your bower.json and inject the path for the module into you requireConfig. Basically you can bower install anything and just start requiring!
yo famous is working just fine!
it was my mistake to try to set relative paths inside requireConfig including images: that is not working but i don't know if it is supposed to!
you have to use relative paths for every image and everything will be ok!
Related
When i publish a dotnet core project, it generated a single folder with hundreds of framework and native runtime files in it.
I understand that these files are required to make everything work, but can i move them into a subfolder and still get my app to run?
For example
MYAppFolder\
MyApp.exe
MyApp.exe.config
native\
hostfxr.dll
netstandard.dll
...
Is there some sort of probing path configuration that can do this?
As far as I can see you have a Standalone (SCD) app.
For that type of deployment hostfxr.dll should always exist in the app directory by convention.
As to other deps, you are able to move them to any locations, however you'll need to edit [AppName].deps.json for every build and also specify Additional probing paths. Besides, you are free to remove all the redundant dependencies (from deps.json and the file itself) if you are sure that you don't use them.
Check this demo where I've put all the dependencies of a Standalone app that could be moved to other location to a lib subdirectory.
please, note the following:
Additional probing path is set in HelloWorld.runtimeconfig.json but you can also use --additionalprobingpath [path] argument or Environment varibable
I've removed relative paths in deps.json file because otherwise I would have put the files to those relative paths sub directories - Additional probing path is considered to be a NuGet package cache thus have a package layout inside.
Also, consider having a Portable (FDD) type. You'll have a much less footprint and more flexibility arranging the files.
I'm trying out semantic-ui in a meteor/npm environment and am left a little dissatisfied with the install process. I love the interactivity, but it's made a mess of my project. I now have semantic folders inside my node_modules directory and outside, a semantic.json config file in the root, and my node_modules directory is now just completely full of ugly gulp folders (node_modules was empty before the install). Is this how it is supposed to go? If so, I'm out, I want to keep it clean, simple, and contained.
I also faced this issue. I ended up doing the following:
npm uninstall gulp semantic-ui
And add semantic like this:
create an empty custom.semantic.json file within your client library folder. suggested location of /client/lib/semantic-ui/custom.semantic.json depending on your applications structure
Run in termnial meteor add semantic:ui flemay:less-autoprefixer jquery
That way you have 1 folder of semantic inside your lib.
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
I'm using JetBrains PhpStorm, which is probably the most epic IDE I've ever used.
The question is simple. How do I add Compass syntax support to it? I've got it installed, it renders and works, but PhpStorm still complains about undefined imports and mixins.
How can I resolve this? Can Compass be included as an external library?
Edit: I'd just like to note that this feature request is for the RubyMine IDE (also by JetBrains), it's not for PhpStorm/WebStorm.
It's explanation of Martin's answer.
Symlink to compass gem directory in your sass folder works great.
Instruction(Windows)
open cmd with admin privileges
change path to your project sass folder, for example cd projectname\sass
run mklink /d compass $GEM_LOCATION\frameworks\compass\stylesheets\compass, as for me $GEM_LOCATION = C:\dev\Ruby200\lib\ruby\gems\2.0.0\gems\compass-0.12.2
Thats all, now PhpStorm will not highlight compass mixins as errors, and will add them in autocomplete suggestions.
Warning: If you want to delete created symlink DON'T use delete, it will remove source directory.
open cmd with admin privileges, cd $yourProjectSassPath, and run rmdir compass
As the above user mentioned it also works to add the path to the Compass stylesheets as a resource directory in your project.
For example, my compass stylesheets are located at:
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/compass-0.12.2/frameworks/compass/stylesheets
Go to Settings > Project settings > Directories.
Add a content root
Add the compass stylesheets directory
Click 'Resource Root' (the blue icon)
When you apply you will see that PhpStorm finds the compass stylesheets without any problems. You can even ctrl+click (windows) on them to open them directly.
Good luck!
I solved it by placing a symlink of the compass-directory (from $GEM_LOCATION/frameworks/compass/stylesheets/compass) into the folder where my stylesheet lives. It's more of a workaround but it makes me and the phpstorm-inspections/-autocompletion happy.
I think it's better to add the directory in the Directories settings: http://www.jetbrains.com/phpstorm/webhelp/directories.html
In the example above, add a new content root of C:\dev\Ruby200\lib\ruby\gems\2.0.0\gems\compass-0.12.2.
This is more easily fixed by using a better source for the executable.
From: http://youtrack.jetbrains.com/issue/WEB-9139
In Windows, use an executable path like:
C:\Ruby200\lib\ruby\gems\2.0.0\gems\compass-0.12.2\bin\compass
While on the Mac use something like:
/Library/Ruby/Gems/2.0.0/gems/compass-0.12.2/bin/compass
When I build my h5bp project, the published html files do not include an updated reference to the versioned css file (they still point to 'css/style.css' rather than the newly made css file). The index.html file is the one exception to this.
Is there a step that I am missing while creating the site or while running $ ant build?
Thanks
It seems there is a mismatch between the stable h5bp version and the current version of their ant-build script. The ant-build script assumes a different directory layout for JS files.
Anyway, they've included some compatibility options in "/build/config/project.properties". Look for the paragraph starting with "# Compatibility with older versions of html5boilerplate", uncomment the following lines and build again. It should work now.