financial-times / origami-build-tools Goto Github PK
View Code? Open in Web Editor NEWStandard Origami component development tools.
Standard Origami component development tools.
Could we consider refactoring this to use an industry wide task runner instead?
Eg. Grunt, Gulp, Make
Results of the meeting to discuss Origami build process:
It's proposed that we modify origami-build tools to build it around Gulp, and make it possible to use it as a CLI tool (in which case you don't need any npm dependencies in your module or product), or as a Gulp config plugin, in a similar manner to that advocated by ft-frontend-build, in which case you do need Gulp in your project. But that pattern should be reserved for products, and only those that use Node.
Usage for modules will mirror the existing setup, ie commands like:
origami-build-tools install
Should continue to work as they do currently. Usage in products will most likely involve creating your own gulp file and importing tasks from the origami-build-tools. Propose the following atomic tasks:
And these higher level ones:
Standalone option of browserify should be available using OBT, which would export a global variable with the value of module.exports of main.js.
Is there any reason why we can't publish this on npm?
The build tools automate the process of ruby dependencies, why not ruby itself?
RVM should be used in any environment where process.getuid is available and set to 0 (Ruby installer has to run as root).
For windows the ruby installer can be downloaded and run in silent mode (/silent or /verysilent) so it doesn't prompt the user for anything.
Example:
margin
should be written more concisely as 0 0 20px
instead of 0 0 20px 0
. Adding 0 to the end is not wrong in my opinion.
Another example:
padding
should be written more concisely as 8px 8px 0
instead of 8px 8px 0 8px
This is wrong, how should I add left padding?
e.g. origami-build-tools watch -tasks [list of tasks to carry out]
I'm happy to do this [it's quite simple] but just wanted to check that there's general agreement (or otherwise) that this is a sensible idea.
Things to check:-
jshint origami.json
outputs 0origamiVersion
is set to 1 (probably not worth doing anything that future-proofs this against future versions because we currently have no idea what an origami v2 might look like)In some cases, one might want to use certain modules only in a demo, and not the whole module, like o-colors does with o-grid and o-techdocs. Right now, you would have to manually add the build service link requesting the css for those modules, and every time you build the demos, that will be lost and only the link to the demo sass file will be added.
Could we maybe add a property to the config file called dependencies for demos?
Since the spec allows for a component to have it's own .jshintrc file, could the verify command use this (if it exists)?
Currently, install
will install the Ruby sass gem regardless of whether it's already installed. This makes it needlessly slow when running it locally.
There should be a check to see what version, if any, is already installed.
Otherwise they don't show up
Can we add a grunt wrapper for the build task (or document how to write your own if it's relatively simple)
When using OBT to build demos, it should also populate the demos
property in origami.json
, to ensure this always matches up with the demos that have been created.
Perhaps it should remove the property when you build for --local
, and populate it only when you build for --buildservice
.
Does this look OK?
Running origami-build-tools verify
will do the following:
main.scss
is present, run scss-lint (using our agreed config)main.js
is present, run jshint (using our agreed config)and output the results.
Should this be --watch
able?
In future we could build in custom checks for Origami compliance - checking presence of origami.json
etc.
We should add csso to the standard build process. It's in the build service and ft-frontend-build, not currently in the manual build tutorial or obt.
Maybe agree on a convention that module developers, and event product developers add their test command to their package.json, and then obt test will run npm test.
This is a bit of a placeholder issue because I don't fully understand what the build tool does or what the intention is. @dansearle-ft explained it but still not 100% on what I'm meant to be doing.
When I run the demo build (for local development) it changes the origami.json file and creates HTML files that shouldn't be commit. It's not obvious why this is or what I should be commit or adding to .gitignore
Could all built demo files that should not be commit be place in a .tmp folder if they are for local use only? We can then just add .tmp to all .gitignores (including the one in the spec).
Also I would rather the tool didn't change the origami file for me, but rather direct me to make the change. If it does need to make a change then it should ask me if it's ok to update the file. Looking a the files changed in git status is surprising when there are changes.... Am I meant to commit them or is there weirdness happening?
Would be good to have sass output expanded and browserify in debug mode with src map when building a local demo
Otherwise, when a new version is released, it could cause build failures.
3.3.3?
Adds <script src="undefined" />
to the html at present
So the command is shorter:
origami-build-tools demo --local --watch
or even, since --buildservice
is already the default:
origami-build-tools demo
Let's say you are in your git repo folder, where a .gitignore will contain this:
/bower_components
/node_modules
Git reads them as "absolute to the folder of the repo".
verify.js runs the pathsToGlob function for each entry in the gitignore file, and tries to identify if they exist and if they are folders. Passing an absolute path to the fs.existsSync will try find the path relative to the root of file system and not relative to the folder of the repo, this will miss to interpret the path as a folder, and will generate wrong ignore entries. The result: linting will run on everything inside node_modules and bower_components folder.
Solution: add process.cwd() before a path that is absolute.
This should be consistent (either shorthand or expanded or both allowed).
In my opinion shorthand color code is good.
So I don't have the special .bowerrc
file, I run bower install
and it doesn't work. Then I run the build tool and it works.... because it magically resolved the dependency locations... perhaps rather than magically fixing this we could check for the existence of the file and tell the developer to fix it.
... And ideally suggest the best version of 3.3 that is tested :-)
Which just runs npm install -g https://github.com/Financial-Times/origami-build-tools/tarball/master
And some way of notifying users that their copy of build tools is out of date would be nice
And a post install script in package.json which runs origami-build-tools install (or at least the bit of it that installs non-npm dependencies)
Running origami-build-tools verify
for o-ft-forms. You just get this:
scss-lint
No SCSS files specified
2 errors
There are .scss
files in the module...
For js
For sass
Support doing something like this and instead of passing it html, be able to pass it mustache templates.
So users know when their installation of origami-build-tools is out of date.
Depth limit is 3, but in the usecase of comment integration (where default Livefyre CSS should be overridden), a deepness much bigger than 3 is needed.
Because Livefyre is using deeper CSS selectors than 3, and our selectors need to be more specific to override, this limit should be either increased or removed.
To speed up install
command locally.
I've used this and it's quite nice. https://github.com/evanshortiss/lintspaces-cli
Suggested use of lintspaces (probably a better way to do files but good enough to test hack):-
lintspaces -n -t -d "tabs" -i js-comments `find . -name "*.js" ! -path "./node_modules/*" ! -path "./bower_components/*"`
I would have made a pull request but it's really quite tricky to add tasks. Raising a separate issue about this.
[Full disclaimer - even though I am suggesting tabs here, in my own time, I use spaces: https://github.com/matthew-andrews/offline-todo-api/blob/master/package.json#L9]
At least that seems to be the cause. Example build failure:
https://travis-ci.org/Financial-Times/o-dom/builds/23515390
It seems to get stuck on installing phantomjs, give up and then skip the bower install
.
Running the equivalent commands instead of origami-build-tool install
resolves the problem.
<script src="main.js" />
Also, when the demo just uses the main.js
(or main.scss
), the --buildservice
version should just use the normal bundles URL.
requireText should be declared as a valid global variable in jshint.json, as textrequireify is used as a transform for the browserify build.
Not sure which project this issue should be created under...
I see this added to all the demos created by the build tools.
<script src='http://registry.origami.ft.com/embedapi?autoload=resize'></script>
Why is it necessary? Resizing the iframe is something the parent window can do... there are no CORS issues to prevent this.
$ obt verify
fs.js:432
return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
^
Error: ENOENT, no such file or directory '/Users/rhys.evans/Sites/o-modules/o-cookies/.gitignore'
at Object.fs.openSync (fs.js:432:18)
at Object.fs.readFileSync (fs.js:289:15)
at Object.getGitIgnorePaths (/usr/local/lib/node_modules/origami-build-tools/lib/files.js:133:22)
at createScssLinterTask (/usr/local/lib/node_modules/origami-build-tools/lib/commands/verify.js:53:30)
at exports.run (/usr/local/lib/node_modules/origami-build-tools/lib/commands/verify.js:93:9)
at Object.<anonymous> (/usr/local/lib/node_modules/origami-build-tools/lib/origami-build-tools.js:70:3)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
We now support a new demo syntax (see Financial-Times/ft-origami#184). The build tool should write the new syntax, or not write the demo list in the origami.json at all.
https://github.com/Financial-Times/o-grid/blob/master/demos/test.html#L10 shows
<link rel="stylesheet" href="/bundles/css?modules=o-grid:/undefined" />
Because there's no stylesheet for this demo. That said, there ought to be a stylesheet for this demo so there's actually a bug here in grid as well, which may get fixed before the issue in obt.
Current output is
$ obt verify
scss-lint
1 errors
Camel case classes are valid class names, they work perfectly, I don't see the point to force them to all lowercase. All lowercase is harder to read as well.
Example: Class deleteInProgress
in selector should be written in all lowercase as deleteinprogress
Currently on failing no errors are output
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.