I am using assemble (https://github.com/assemble/assemble) via a grunt plugin to build static pages.
I have been using grunt for a while now so understand how it all works, yet this is my first time using assemble so I looked at this for ref (http://blog.parkji.co.uk/2013/07/06/building-a-static-site-using-grunt-and-assemble.html). Everything seemed to be working fine.
However, I want to introduce JSON data to the mix and have looked at the docs on the assemble site (http://assemble.io/docs/Data.html) yet after I run 'grunt assemble' it doesnt render the json data :(
My gruntfile
assemble: {
options: {
layout: "src/responsive/layouts/default.hbs",
data: 'src/responsive/data/**/*.json',
flatten: true
},
pages: {
files: {
'src/': ['src/responsive/pages/*.hbs']
}
}
},
test json:
{
"name ": "This is a square widget" ,
"modifier ": "widget-square"
}
and folder structure:
- data
-- index.json
- layouts
-- default.hbs
- pages
-- index.hbs
Within pages/index.hbs I am trying to call {{ index.name }} or simply {{ name }} (I have tried both) to no avail.
Im pulling my hair out as grunt is giving no errors (and in fact if I make json not valid grunt complains so it is reading it).
Any help much appreciated before I go crazy....
Thanks,
Adrian
Your JSON here is the issue. You had extra spaces in your keys. Your JSON should be formatted as the following:
{
"name": "This is a square widget",
"modifier": "widget-square"
}
Related
Hi there I have been forced to come here due to every resource out there on the topic is very poor and incomplete.
Not only on the babel site but every single post out there is not complete and informative enough.
I tried to reach out at the babel forum and no replies.
I am trying to convert my prototype libraries to Es6 and convert to the most leanest possible code. So no bloaty duplicated generated code and if possible no bloaty requirejs and whatever browserify generates.
I have tried to make a project with grunt and babel directly, configure the external-helpers plugin according to the babel documentation.
It fails to include the relevant helper code and fails to include the import module code altogether.
ie a babel config like
{
options: {
sourceMap: false,
presets: ['es2015'],
"plugins": ["external-helpers"]
},
dist: {
files: {
'build/<%= package.name %>.js': ['src/<%= package.name %>.js']
}
}
}
The main project file has an import like
import Button from './ui/buttons/Button';
The module code looks like this as if the export is placed underneath extra code is generated for that.
export default class ShareButton {}
produces an output like this
Object.defineProperty(exports, "__esModule", {
value: true
});
require('babel-core/external-helpers');
var _Button = require('./ui/buttons/Button');
var _Button2 = babelHelpers.interopRequireDefault(_Button);
No source of the module or the helper object is included.
I searched hard for how to deal with external-helpers and it suggests it has to be imported into a separate file ie something like this to generate only the helper functions needed
babel-external-helpers -l createClass > src/helpers.js
But any resource regards to this fails to go as far as to how to import that into the project.
If I use the transform-runtime plugin, it produces a massive polyfill that cannot be disabled so a bug and not so useful for what I need.
"plugins": [
["transform-runtime", { "polyfill": false, "regenerator": false }]
]
If I use browserify / babelify it makes a royal mess and duplicates code still.
A config like
{
options: {
"transform": [["babelify", {
"presets": ["es2015"],
"plugins": ["external-helpers"],
sourceMap: false
}]]
},
dist: {
files: {
'build/<%= package.name %>.js': ['src/<%= package.name %>.js']
}
}
}
Produces code like this still with the external helper missing and duplicated code not relevant to the helper. ie
Object.defineProperty(exports, "__esModule", {
value: true
});
Is within every module in the generated file.
If I export the classes like this at the bottom of every file
export default class {}
Duplicated code is generated like
var _class = function _class() {
babelHelpers.classCallCheck(this, _class);
};
exports.default = _class;
In terms of filesize that doesn't include bloaty wrapping code like
},{}],2:[function(require,module,exports){
It seems concatting all the prototype classes files together to bundle in one file is the winner still.
So trying to port the library but keep it similar and bundle it together into one file.
Hopefully this is concise enough and there is a simple solution.
FYI browsers do not understand tabs and 4 spaces. I had to edit this post in my editor to get the code blocks working ! It would be nice to have a markup like other places like "```" ?
Let me know thanks.
I'm using rollup with babel now. Rollup produces a clean output as umd mode. Browserify is really bloaty in itself.
There is just a problem with polyfills being converted. I have to concat external ones in like for WeakMap.
I had a problem trying to use the generated Iterator and finding a polyfill for that so I have to code loops a particular way it doesn't generate Iterators.
The polyfill generation in babel is still too bloaty and crazy. It's pretty terrible. So I concat in minified polyfills that are very small and it's used globally.
I was running into something very similar. Was tired of trying to do it the "right way" and ended up just creating https://www.npmjs.com/package/grunt-babel-helpers which simply manipulates the string output.
I am building an angular app, with internationalization using angular-gettext.
I would like to know how to better automate the workflow when updating the translation files.
Currently it is the following:
- running "grunt" (generation of pot file + translation files)
- opening all "po" files in poedit
- in poedit, update po file with the new "pot" file
- update translations in poedit & save
- run grunt again
Is there a way to have something better?
Like, is it possible to apply the pot file to all "po" files using a grunt command?
Here is my gruntfile currently.
Thanks a lot
module.exports = function(grunt)
{
grunt.initConfig({
nggettext_extract: {
pot: {
files: {
'po/template.pot': ['www/app/**/*.html']
}
},
},
nggettext_compile: {
all: {
options: {
module: 'app'
},
files: {
'www/resources/translations.js': ['po/*.po']
}
},
}
});
grunt.loadNpmTasks('grunt-angular-gettext');
// Default task(s).
grunt.registerTask('default', ['nggettext_extract', 'nggettext_compile']);
}
poedit doesn't have a command line argument to execute the "Update from pot" file feature. So I don't think it will be possible with it.
Actually there is a way to do this!
We wrote grunt tasks to call command line gettext utilities. They are also available for windows here.
Basically you need to call msgmerge with the po file and the pot file to update it. See the online documentation for msgmerge to see what you may need. It's pretty slick once you get it going.
I have this assemble grunt target:
docs: {
files: {'<%= site.tmp %>/': ['<%= site.pages %>/**/*.html'] }
},
If there is no matching content, it complains, saying "Warning: Source files not found. Use --force to continue". The task then aborts. I don't mind the warning but I would like the option to configure the task to continue rather than having to use "--force" on the command line. Is this possible?
ps. The reason why this task is now failing is that I have converted the content to markdown. I am trying to build a scaffold that allows users to use markdown, hbs or html in any combination.
Based on what you are saying, you can use a little unix trick here.
docs: {
files: {'<%= site.tmp %>/': ['<%= site.pages %>/**/*.{html,hbs,md}'] }
},
That code basically looks for anything ending in .html, .hbs, or .md.
Since this is really a Grunt error, you would need to simply write your file object to allow for more possibilities.
For example, the above would only work if the location actually has files. If Grunt looks in that location and doesn't see any of the acceptable files, it will display the error you are getting now.
I have a number of backbone apps all hosted on the same site. I am attempting to use grunt-manifest to generate appcache manifests for them. It generates the manifest file, but the links are wrong. I want each app to have a separate manifest file.
For example say I have an app called 'hello', it would be accessed via this url:
mydomain.com/apps/hello
so the main js and css files would be at:
mydomain.com/apps/hello/app.js
mydomain.com/apps/hello/style.css
etc.
There are also some shared components, found at say:
mydomain.com/shared/shared.js
(I dynamically load these with require.js so don't want to concat into the main app.js)
I specify the manifest in grunt like this:
manifest: {
generate: {
options: {
basePath: '<%= gconf.dist_dir %>/',
timestamp: true,
network: ['*'],
},
files: [
{
cwd: 'public/',
src: [
'apps/hello/*',
'shared/*',
// etc
],
dest: '<%= gconf.dist_dir %>/public/apps/hello/manifest.appcache' },
]
}
},
I believe the issue is I am trying to get grunt-manifest to generate an appcache manifest for a portion of a site not the root site. The manifest i get looks like this:
CACHE
apps/hello/app.js
apps/hello/style.css
shared/shared.js
When I load the page - the manifest retrieval fails because it is trying to access links like this:
mydomain.com/apps/hello/apps/hello/app.js
If I manually edit the manifest files and add a '/' in front of everything so it looks like this:
CACHE
/apps/hello/app.js
/apps/hello/style.css
/shared/shared.js
...then it all works.
The issue obviously being the manifest creating relative links, when I want them from the root.
I cannot for the life of me figure out how to get grunt-manifest to create these for me with a '/' in front.
I've tried experimenting with 'basePath' on its own, 'cwd' on its own, a combination of the two. If I leave the '/' off the end of say basePath or cwd and try adding it in the 'src' it doesn't work and I get an empty CACHE section.
I'm sure there must be an easy way of doing this with the grunt globing patterns, but I just can't work it out.
Any ideas?
(also - not enough rep to create a new tag, but a 'grunt-manifest' tag might be useful for others in the future)
I just ecnountered the same issue.
I've forked the module here: https://github.com/killfish/grunt-manifest
If you pass in the option absolutePath : true, it will prepend a '/'
options: {
**absolutePath: true,**
network: ['http://*', 'https://*'],
preferOnline: true,
verbose: true,
timestamp: true
},
So in my config file, I'm statically defining the css files to watch, along with some html partials. (eventually I will minimatch with exclusions .. I'm just going with first pass right now)
Originally I was storing these in the grunt config object, but struggled to get the output I wanted, so I moved them out of the initConfig method and into the wrapping function:
Original pass:
grunt.initConfig({
cssFiles: [ ... list of files ... ],
htmlFiles: [ ... list of files ...],
watch: {
reload: {
files: ['<%= cssFiles.concat(htmlFiles).join(",") %>']
}
}
});
I tried several variations of this (with and without join), as an example.
Current "Working" version:
module.exports = function(grunt) {
var cssFiles = ['someFile.css',...'lastFile.css'],
htmlFiles = [ ... ];
grunt.initConfig({
watch: {
reload: {
files: cssFiles.concat(cshtmlFiles)
}
}
});
};
I feel like I should be able to do this without having to move my array's out of the grunt config (although I don't know WHY I feel they should stay there ... I guess I just haven't seen many Gruntfile's with code outside of initconfig)
I'm using a system that stores all the paths I need in a single config object, like so:
grunt.initConfig({
pathTo: {
distcss : './dist/css/master.css',
srcstyles : './lib/styles/**/*.scss',
vendor : './lib/vendor'
},
// tasks...
});
Then, I load those in via underscore templates like in your first example. If your project is structured in a good way then usually just having one minimatch pattern is enough. All my CSS ends up in lib/styles, and any misc. third party stuff is usually in lib/vendor as that is managed through Bower.
With the right directory structure and pattern you shouldn't need a large array of paths. A sample JavaScript project could look like this:
lib
└── src
├── app
└── tests
Then your minimatch pattern to lint your application and test code would just be lib/src/**/*.js, for example.
But what works for you works for you; if you've written a system that you're happy with, regardless of whether you've seen it elsewhere or not, there's no reason to change it. :-)