npm package

[andrezsanchez]

I noticed that the package for semantic in npm wasn't Semantic UI. I am using Browserify (which uses npm packages for front-end code).

I should be able to get around this fine, but I think that it would be good for Semantic to follow the convention of having the library available in npm.

[brigand]

You wouldn't want to require everything in Semantic-UI using browserify, so each component would have to be packaged separate.

The main problem is that you don't get the CSS with it when browserifying; which makes it mostly useless. Have any thoughts on how this could be fixed?

I could do this when I run my CDNJS task; if no one has any opposition.

[andrezsanchez]

As long as the compiled CSS is in the package then anyone could just make copying the CSS file to another folder part of their build process.

[brigand]

How should the exports be handled? I'm thinking something like this:

// one file where you require the needed components
var $ = require("jquery");
$.fn.dropdown = require("semantic-dropdown")($);

// in another file
var $ = require("jquery");
require("tha_module.js");

$(something).dropdown();

The benifit of the above is it doesn't expect that the user will have jQuery included in any particular way. Some users will include jQuery in their bundle; some will shim it; and some will just assume the global exists, so we don't want to assume.

To aid build scripts, I'm thinking we could also have a main module which will allow you to grab the style sheets from the packages (it's going to be a very tiny wrapper around fs).

// build script
var semantic = require("semantic-ui");

// could also include an array of module names to check
// defaults to all
var semanticCSS = semantic.css().join("\n");

// if you're not using browserify
var semanticJS = semantic.js().join("\n");

And the installation looks like this

$ npm install --save-dev semantic-ui
$ npm install --save-dev semantic-dropdown

[andrezsanchez]

That way of exporting would be great, using separate packages like that would really be nice!

It would be nice for some people to just have a single entry point as well, if you feel lazy and just want the whole thing. The main module should probably just require all of the modules and supply them into the provided jQuery object.

Something like

require('semantic-ui')($)

That build script would be nice for some I'm sure, though maybe putting it in a specific folder would be more appropriate.

So you could do like

var semanticBuilder = require('semantic-ui/build-helpers')
semanticBuilder.css().join('\n')

// or specific build helpers
var semanticCss = require('semantic-ui/build-helpers/css')
var css = semanticCss().join('\n')

[ahdinosaur]

+1 for separate npm packages. modular imports are what i've loved about using semantic-ui with less.

also, if anyone wants to use semantic right now with browserify:

npm install --save jquery
npm install --save Semantic-Org/Semantic-UI

then for js requires

require('jquery');
require('semantic/src/modules/dropdown.js');

and less imports

@import './node_modules/semantic/src/elements/header.less';

[Anachron]

The best for me would be:

npm install semantic-ui-base
npm install semantic-ui-header
npm install semantic-ui-buttons
npm install semantic-ui-builder

semantic build header, buttons
... 
Finished! Output:
.../semantic.bundle.js
.../semantic.bundle.css

[jlukic]

The difficulty is running each semantic ui element/collection/view/module as a separate repo. I think I'd pull out my hair if I had to switch between 20+ repos for updates

[brigand]

I agree one repo is best.

Sorry I haven't finished this yet, I've been very busy.

On Mon, Mar 3, 2014 at 8:44 PM, Jack Lukic [email protected] wrote:

The difficulty is running each semantic ui element/collection/view/module
as a separate repo. I think I'd pull out my hair if I had to switch between
20+ repos for updates

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/517#issuecomment-36591816
.

[ahdinosaur]

so if the issue is closed, does that mean this is on npm now? search results for 'semantic'.

[brigand]

I created the basic task to build a npm package. It can be used like this:

$ = require('jquery');
$.fn.dropdown = require('semantic-ui/modules/dropdown')

I'll do the build tools later; probably when the css branch merges down so I can include less variables.

For now, I'd use cssify which is a really awesome browserify transform. Just require a css file, and it'll end up being applied to the page. You can also do other things, e.g. with grunt's concat to build up the files yourself.

require('semantic-ui/elements/buttons.css');

It's the npm-package branch of my fork.

---

@jlukic grunt release will build the package. Then cd npm and do the normal npm publish.

[mishu-]

Can you please put up a tutorial for this? Thanks!

[brigand]

@jlukic could you publish the npm package? I'll make a guide on the wiki for using it with npm.

[geekytime]

As a browserify user, it would be awesome to be able to npm install semantic-ui.

Is it still in the works to publish the official npm package?

[brigand]

@jlukic ping :-)

[brigand]

@geekytime @ahdinosaur @Anachron I've temporarily published it as semantic-ui-temp.

It's just the npm director from master. Please leave semantic-ui available for when @jlukic is ready to publish it.

[ahdinosaur]

thanks @brigand. :)

[jlukic]

Sorry about that, missed this thread.

Just published the package: https://www.npmjs.org/package/semantic-ui

[AnsonT]

I'm running into a problem using the npm package in Browserify with the js files. The functions reference 'module' variable within $allModules.each(...) loop. The 'module' variable is undefined within the function context. I'm preparing a PR to fix this. Has anyone else ran into this problem?

[jlukic]

Module is defined inside each component.

Let me know if you find anything else

[AnsonT]

I'm using the modules in Browserify. The problem is with the settings part: where '$.fn.example.settings' is replaced with 'module.exports.settings'. The settings variable should be referring to the exporting module (which was available as $.fn.example, but not available inside a require) and not the 'module' that is defined later in the function. My fix is to replace '$.fn.example.settings' with 'exports.settings' . https://github.com/substack/browserify-handbook#exports

More specifically, the module variable is redefined in the $allModules.each() predicate function and hides the passed in module parameter.

[AnsonT]

Created a fix PR: #1156