Git Product home page Git Product logo

atomify-css's Introduction

Atomic web development - Combining the power of npm, Browserify, Rework and more to build small, fully encapsulated client side modules

Description

Atomify provides a centralized point of access to atomify-js and atomify-css both in code and on the command line. It also offers a server with live-reload and on-the-fly bundling support to make development a breeze.

Examples

You can learn from examples in this repository

API

atomify(opts, cb)

Just like its constituent pieces, atomify is a function that takes an opts object and a callback function.

opts

opts.js - Options to be passed to atomify-js

opts.css - Options to be passed to atomify-css

opts.assets - Used to configure opts.js.assets and opts.css.assets simultaneously (and identically). See links above.

opts.server - Options to be passed to the development server

callback

Just like the callbacks used by atomify-js and atomify-css, but with a third parameter to denote the type of bundle being provided. cb(err, src, type) where type is either 'js' or 'css'.

API Example

// build.js
var atomify = require('atomify')

var jsConfig = './entry.js' // shorthand for {entry: './entry.js'}

var cssConfig = {
  entry: './entry.css'
  , variables: {
    background: '#f00'
  }
}

function cb (err, src, type) {
  if (type === 'js') {
    // do something with JS source bundle
  } else {
    // do something with CSS source bundle
  }
}

atomify({js: jsConfig, css: cssConfig}, cb);

If you don't need to access the bundled source simply provide a file path as the output property in your options and atomify will write the file for you.

atomify.js and atomify.css

As a convenience, you can access atomify-js and atomify-css via properties on the atomify function.

var atomify = require('atomify')

atomify.js === require('atomify-js')
atomify.css === require('atomify-css')

Development server

Atomify includes a development server that provides things like on-the-fly bundling and live reload/browser sync support to make your workflow lightning fast. atomify.server(opts) provides basically the same API as atomify itself, with a few extra options (documented below) added in. The biggest difference, of course, is that instead of writing to a file or calling a callback function, atomify.server responds to http requests. The server can also be configured by including a server property in the opts object when calling atomify(opts).

Just like with atomify, the options passed to atomify.server are expected to have a js and/or css field. When the entry option of either of these is requested, the server will return the results of bundling your code. If you don't want to include the actual path to your entry file in your HTML you can also provide an alias option field. When the alias path is requested the server will bundle using your entry path.

opts.server

You can provide server-specific options in this field.

opts.server.port - Port to listen on. Default: 1337

opts.server.open - If provided, open the URL in your default browser

opts.server.path - The path to open. Appended to http://localhost:port by default. Default: /default, which is a generated HTML file that includes your CSS and JS bundles automatically.

opts.server.url - Full URL to open instead of http://localhost:port/path

opts.server.hostname - Use your machine's local hostname (via Node's os.hostname()) instead of localhost. Ideal for accessing pages from mobile devices on the same LAN. Aliased as h.

opts.server.lr - Enables live-reload support by injecting the live-reload script into any HTML pages served. Supports the following sub-properties.

  • sync: Use BrowserSync. Aliased as s. If provided as an object will be used as the ghostMode option for BrowserSync.
  • port: Port for BrowserSync server to run on. Default: 3000
  • patterns: Globbing patterns to pass to browsersync for watching. Default: ['**.html'] relative to process.cwd() as well as all files in the dependency graph of your JS and CSS bundles.
  • quiet: Suppress file change notifications on the command line. Default: false
  • verbose: Log BrowserSync's debugInfo to the console. Default: false

opts.server.sync - Shortcut for specifying opts.server.lr as {sync: true}.. Aliased as s.

opts.server.st - Options to pass to st static file server, which is what serves all non-entry/alias requests.

opts.server.html - Override the default HTML served at /default. Pass either a filepath or a function.

If you pass a function, you'll be passed one options argument with the urls to the bundled JS and CSS. You should insert those into your HTML, and return a string.

{
  server: {
    html: function html (paths, done){
      // it's important to include the body tags so that the livereload snippet from browsersync can be inserted
      var html = '<body>'
        + '<link rel="stylesheet" href="' + paths.css + '">'
        + '<h1>your current url ' + paths.request + '</h1>'
        + '<script src="' + paths.js + '"></script>'
        + '</body>'

      // you can return an error if something went wrong
      done(null, html)
    }
  }
}

If you pass a filepath, the bundled JS and CSS will automatically be inserted at the bottom of your file. However, you can place the strings __ATOMIFY_CSS__ and __ATOMIFY_JS__ when you want the relevant paths inserted to override this behavior.

opts.server.spaMode - When set to true, the default HTML will always be served. This is useful for single page apps that have a router.

package.json config

In order to support atomify turtles all the way down, you can also specify your configuration in package.json. Simply recreate an opts object structure in JSON with atomify as the key. (Omit output properties if not a top level package.)

{
  "atomify": {
  	 "server": {
  	 	"lr": true
  	 },
    "js": {
      "entry": "index.js",
      "output": "dist/bundle.js"
    },
    "css": {
      "entry": "index.css",
      "plugins": [
        ["rework-plugin-inline", "src/assets"],
        "rework-default-unit"
      ],
      "output": "example/bundle.css"
    }
  }
}

For detailed information on configuring Rework plugins in package.json see the relevant section of the atomify-css README.

CLI

Thanks to subarg, nearly everything you can do in code or JSON, you can do on the command line. JS options can be specified in a --js, -j subarg context and CSS options can be specified in a --css, -c subarg context. Server options can be specified in a --server, -s subarg context.

If you supply the --debug, -d or --output, -o args outside the --js and --css contexts they will apply to both JS and CSS bundles. When providing an --output argument that applies to both, omit the file extension and it will be applied correctly for you.

You can also configure aliases by appending them after a : in your entry field like -j [ entry.js:/bundle.js ].

Get a complete listing of options by running atomify --help

CLI Examples

atomify -j [ entry.js bundle.js ]
atomify -j [ -e entry.js -e other.js -o bundle.js -d -w ]
atomify -j [ entry.js -t funkify ] -c [ entry.css ] -o bundle
atomify -j [ src/entry.js:bundle.js ] -c [ styles/entry.css:bundle.css ] --server [ --open ]

Any top level args (js, css, server) passed on the command line will override the corresponding configuration defined in package.json. Non-conflicting top level items will be merged with package.json configuration.

Install

npm install atomify

atomify-css's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

atomify-css's Issues

less sourcemaps missing/broken

This is not really a bug, just sharing my attempts to make things work with the less version of bootstrap.

It seems that npm-less is using an ancient version of bootstrap to compile the code that doesn't support inline sourcemaps, and using it as it stands now it just points to a missing file on the build folder.

So, I upgraded npm-less to use the lastest version of less and then tried with this:

/* app.less */
@import 'bootstrap';    
body {
  background-color: #1c1c1c;
}
// atomify
atomify.css({
  entry: './app/styles/app.less',
  sourceMap: true,
}, 'build/app.css');

The output now has an inline sourceMap at the end of the file but it also has an extra sourceMappingURL at the end of the inlined bootstrap code, which is pointing to a non-existent file:

/*# sourceMappingURL=bootstrap.css.map */

If I replace the above with an empty line, then I can see that the sourcemap that it's at the end of the file is pointing to the dist/css version that comes with the bootstrap module... :?

If I don't import bootstrap at all and just try to compile a basic example, the generated source map it's pointing to a non-existent file in the build folder (build/app.less in this case).

I tried to mess a little bit with the code but it didn't get any better... Hopefully someone with more knowledge about less can take a look...

bower support

would you be open to a PR to introduce bower support ? all that will be done is an option flag can call in rework-bower (will be made) instead of rework-npm

if not i can make atomify-css-bower but would be awesomer and easier to just have it under atomify-css

How do we want to handle referenced images?

Wanted to start a discussion on this.

When a rule contains a declaration like background-image: url(images/layers.png);, how should we handle that? I am assuming the simplest thing would be to just copy the images to a new location relative to the bundle, but the potential for collisions seems high. Namespace image paths by module name? Also, I don't know that this could be done (well) as a Rework plugin, because they run synchronously. Maybe as a post-process step?

/cc @kristoferjoseph @lvivski

watch support

atomify-js has a "watch" option, but atomify-css doesnt have, thus, atomify in "watch mode" will recompile javascript when a change occurs, but a css change will not make the css be rebuild.

File not found (ENOENT) for CSS source map using Bootstrap

I can't get sourcemap bundling working with Bootstrap's CSS, and after some investigation, it seems like it might be an Atomify bug.

It works fine in prodution mode, but I get an error such as the following when running with --debug:

   { [Error: ENOENT, no such file or directory '../node_modules/bootstrap/dist/css/bootstrap.css.map']
  errno: 34,
  code: 'ENOENT',
  path: '../node_modules/bootstrap/dist/css/bootstrap.css.map',
  syscall: 'open' }

The .map file does in fact exist (although I don't know what the path is relative to)

Here's a minimal package.json which you can use to reproduce the problem by running npm run bundle-dev:

{
  "name": "atomify-bootstrap-test",
  "version": "0.1.0",
  "description": "Debug Atomify problem with Bootstrap CSS",
  "scripts": {
    "bundle-dev": "atomify --debug",
    "bundle": "atomify"
  },
  "dependencies": {
    "atomify": "^6.1.0",
    "bootstrap": "^3.3.4",
    "resrcify": "^1.1.3"
  },
  "atomify": {
    "css": {
      "entry": "client/main.css",
      "output": "public/bundle.css"
    },
    "assets": {
      "dest": "public/assets",
      "prefix": "../assets/"
    }
  }
}

The only other file you need is a CSS file at 'client/main.css' containing the line

@import "bootstrap";

I should point out that invoking rework-npm from the CLI doesn't generate such errors (and there is indeed a source map in the CSS, although I haven't checked if it's accurate)

./node_modules/rework-npm-cli/index.js client/main.css -m -o public/bundle.css

(Not sure if this should be an Atomify bug, but I'll leave that up to the maintainers to decide)

Locked entry-file location

Excerpt from package.json:

{
  "css": {
    "entry": "lib/entry.css"
  }
}

Excerpt from lib/entry.css:

@import "font-awesome";

This will fail as the lookup for assets will start from lib/node_modules instead of node_modules.
I'm guessing rework-npm is initialized with the path to the entry-file instead of the projects root?

Nested dependencies

Just out of curiosity, how does this handle nested dependencies?

If two modules depend on another module, but different versions, will both versions be included in the final build? If so, this doesn't really work for CSS single there isn't any scope.

Does it flatten the tree so that you only get one version of each dependency? I realize in practice, most CSS modules don't depend on other modules that much since it's all tied together in the DOM anyway.

SASS support

I was looking through the past issues/commits and see that we removed SASS support. Any particular reason why?

Error: less version 1.7.5 is not currently supported

I recently upgraded from node v4.4.4 to node v6.2.0. After running my gulp build, I got an error

Error: less version 1.7.5 is not currently supported

After doing some research, I ran across gulp-community/gulp-less#208. So I thought I'd just upgrade my gulp-less version to a higher version that supports Less 2.x. I still got the same error.
When I did npm list less I found this:

├─┬ [email protected]
│ └─┬ [email protected]
│   └── [email protected]
└─┬ [email protected]
  └── [email protected]

It looks like bower-less used by atomify-css may be outdated. Is it possible to replace bower-less with something else to fix this problem? Thanks!

Handle plugins failing in prefilter phase

I would like to reopen problem mentioned in #35. I want to use Atomify with rework-inherit and separate the shared classes to a common file. However this is not possible because rework-inherit will fail in the prefilter phase if it doesn't find selector for extension – which is accessible only after concatenation with rework-npm.

I have prepared gist with an actual failing example: https://gist.github.com/jnv/38247f091ffba4951336

What do you think would be the best way to handle it? The failing plugin could be patched to just ignore the missing classes, but I think that'd reduce versatility of atomify-css and it's not the best behavior for the plugin. Alternatively the failing plugins could be just ignored in the prefilter phase, which doesn't seems like a good idea though – however, the exception should be propagated up to Atomify CLI. I guess the best option is to introduce a new configuration option for use in either phase.

Hint for new rework based CSS Project

Sorry, I really tried hard to figure out your mail address but couldn't.
So I create this issue.
I want to point out a new project named VCL (Visual Component Library):

https://github.com/vcl
https://github.com/vcl/doc

This has been cooking for years internally in our company because we did this long
before bootstrap arrived and were never convinced by approaches like Bootstrap which are basically dead blobs.
Now with the power of rework we modularized our stuff into a bunch of modules.
Feature-wise we are already above BS and the module quality is already quite good.
There are still many missing parts like the demo/ doc building but we are working on that.

Why I'm telling you this?

1.) I think it should almost be or is already compatible with atomify-css
2.) It's always good to know what others do in a certain space
3.) Maybe we could team up somehow

Greets, Thomas

Cannot find _bundle.js

After deploying the server when I opent he application I get the following problem.

[BS] Watching files...
ERR! Error: EISDIR, read
ERR! Error: ENOENT, no such file or directory './atomify/lib/_bundle.js'

I could not find anywhere in the web.
You guys know what could be the issue?

Thanks

rework-vars outdated

rework-vars released 3.0 a little while ago with syntax that follows a new spec update (PR here: reworkcss/rework-vars#27)

I ran into confusion with variables being undefined because I was following the rework-vars docs, which won't work with the 2.0 version used in atomify-css. Even if I use the transform directly through the plugins option, the older version gets included first.

LICENSE?

you must include license text when using MIT license

Braces inside comments inside values fail to parse

Hey guys!

This is related to reworkcss/css#24 .

I have some library css files which I'm bundling, and they have comments with braces inside of the values of some properties. Here's an example:

.a {
  background: blue /* This is { blue } */;
}

When I try to atomify this file, I get an error. The one I see with the example above looks like this:

         Error: /Users/danielsuskin/Documents/Code/site/atomify-css/test/fixtures/css/a-with-inline-comment.css:4:1: missing '{'
           at error (/Users/danielsuskin/Documents/Code/site/atomify-css/node_modules/rework/node_modules/css/lib/parse/index.js:64:15)
           at declarations (/Users/danielsuskin/Documents/Code/site/atomify-css/node_modules/rework/node_modules/css/lib/parse/index.js:241:25)
           at rule (/Users/danielsuskin/Documents/Code/site/atomify-css/node_modules/rework/node_modules/css/lib/parse/index.js:554:21)
           at rules (/Users/danielsuskin/Documents/Code/site/atomify-css/node_modules/rework/node_modules/css/lib/parse/index.js:111:70)
           at stylesheet (/Users/danielsuskin/Documents/Code/site/atomify-css/node_modules/rework/node_modules/css/lib/parse/index.js:81:16)
           at module.exports (/Users/danielsuskin/Documents/Code/site/atomify-css/node_modules/rework/node_modules/css/lib/parse/index.js:558:20)
           at rework (/Users/danielsuskin/Documents/Code/site/atomify-css/node_modules/rework/index.js:27:21)
           at applyRework (/Users/danielsuskin/Documents/Code/site/atomify-css/css.js:43:15)
           at /Users/danielsuskin/Documents/Code/site/atomify-css/css.js:36:22
           at Array.forEach (native)

With my library css, I get one more like Error: property missing ':'

Anyway, I was originally planning to fix this by adding the option to pass configuration into rework, so that you could set silent: true, but that just resulted in this output:

.a {
  background: blue /* This is { blue;
}

Which isn't really right. So I figured I'd start by filing an issue. The above is happening for me with the latest atomify-css.

Do you guys have any ideas about the best way to handle css files containing this type of comment?

Thanks!
Daniel

CLI

Wouldn't it be great if we could use atomify from the command line? This makes it immediately work with any build system (and you might not even need one). All it would need is a "bin" field in package.json that points to a node binary. What do you think? </feature-request>

Windows support

At the very least, tests currently fail on windows. There's probably a combo of \n and path.join problems.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.