Comments (35)
Is this for backwards compat with Component or for regular Duo stuff? I can outline how I was hoping the CSS stuff would work if that's helpful
from duo.
i have a good idea of how CSS will work within an app. Basically just point to a single css
file and have that do all the importing so you get the smallest build necessary, but for components i'm not so sure.
yah, if you have some ideas, i'd appreciate it. trying to figure this stuff out now. backwards compat is necessary, but we can also do stuff that will only work in duo
from duo.
What are the other distinctions that we have between "apps" and "components"? I think it's just that main
is implied by the arg you pass to the CLI right now? Other than that it seems the same? Just curious so I can keep my understanding right.
What I imagined was that both cases would have a CSS entry point file, defaulting to index.css
that would contain @import
rules. For apps it would just be something like this I think...
$ duo index.css > build.css
...and then for packages, they would have a main.css
key to define what the entry point is...
{
"name": "toggle",
"repository": "segmentio/toggle",
"main": {
"js": "lib/index.js",
"css": "lib/index.css"
}
}
...and the same rules would then apply.
Makes it easy, since to maintain backwards compat for existing components, we just need to generate an entry point file with imports to everything in styles
...
fs.writeFileSync('index.css', styles.map(function(file){
return '@import "' + file + '"';
}).join('\n'));
...and I think that should cover it?
from duo.
yep, this works for me. then we'll check main
to see if it's a string or an object and act accordingly.
from duo.
Yup, and I even just realized we can nicely check the extension if it's a string for even more convenience for single-use packages:
{
"main": "lib/index", // { js: "lib/index.js" }
"main": "lib/index.js", // { js: "lib/index.js" }
"main": "lib/index.css" // { css: "lib/index.css" }
}
But that might have been obvious to everyone else already :)
from duo.
ohh yah, <3
from duo.
@ianstormtaylor I don't think this is going to work for components that depend on existing CSS dependencies.
I'm not sure how many of them there are, but in order for a component's CSS to depend on CSS from another component in duo, it would need something like:
component/tip:
@import "aurora-tip"
note: component/tip doesn't depend on aurora-tip, this is just for demonstration purposes
Which is definitely not backwards compatible with component. This is probably an edge-case, but I've noticed you've done a lot of CSS components, so I wanted to run this by you.
from duo.
oh... the logo/logo
is a good example. duo
doesn't care about dependencies in the manifest, if there's no reference to them in the CSS. So logo/logo
won't get picked up by logo/apple
.
you think that's going to be a problem?
/cc @yields
from duo.
Just running into this issue again. Was trying to use one of our existing components and its styles
array wasn't getting picked up. Would be nice for backwards compat if we figure out a solution to this, otherwise we have to manually import each of the files itself with a bunch of :/path/to/file
imports
from duo.
Yah... this was a compromise that I'm hoping we can get away with. I think you guys are the biggest and perhaps the only pure CSS component (with deps) users.
The solution I'd like to propose is to update the CSS components to do:
// in index.css
@import "logo/logo";
@import "./some/other/file.css";
...
This has the added benefit of only including the CSS that you need instead of adding all the CSS files in the styles array.
I'm down to help with this transition but I know this ends up breaking component compatibility so let me know if this is not feasible and we can work around it.
Sent from my iPhone
On Aug 3, 2014, at 16:24, Ian Stormn Taylor [email protected] wrote:
Just running into this issue again. Was trying to use one of our existing components and its styles array wasn't getting picked up. Would be nice for backwards compat if we figure out a solution to this, otherwise we have to manually import each of the files itself with a bunch of :/path/to/file imports
�
Reply to this email directly or view it on GitHub.
from duo.
Ah nice I like that interim fix with the index.css
. Sounds good to me!
from duo.
oh i thought that would be a permanent fix haha. what do you have in mind?
from duo.
Ah oops I meant interim as in until we get rid of component altogether. Just liked that it was backwards compat still in the interim as we switch over
from duo.
oh shoot, the rest of the message got cut off becuase i was messaging on my phone... dunno if you saw:
...
This has the added benefit of only including the CSS that you need instead of adding all the CSS files in the styles array.
I'm down to help with this transition but I know this ends up breaking component compatibility so let me know if this is not feasible and we can work around it.
Sent from my iPhone
from duo.
Ah nice, yeah that's also cool. Been digging the total control over ordering of deps in css land compared to before. way more sensical :)
from duo.
yep haha :-)
from duo.
@ianstormtaylor @matthewmueller fyi this actually won't work because check it out:
That seemed like an easy fix. This way, component pulls from style.css
, with all the dependencies coming from the styles
field in component.json
. Then, duo can pull from index.css
with all the dependencies imported with @import
.
However, this doesn't actually work as expected (maybe I just misinterpreted from the beginning).
Duo first checks component.json
's styles[0]
field, and then tries index.css
. Which means it will always pull styles[0]
if it's being ported from component. Which means we can't port it using duo's current handling of this (i.e. we can't support both component and duo at the same time).
It seems like it should work the other way around, if we're not going to be supporting CSS in the manifests (#252), yeah? Basically, duo should first check index.css
, and then fall back to styles[0]
if missing?
from duo.
oh yah shoot, index.css
would happen if it doesn't find anything in the component.json
. Here's the culprit: https://github.com/duojs/duo/blob/master/lib/duo.js#L542
An easy fix would be:
{
"main": "index.css",
"styles": [
"style.css"
]
}
or...
{
"styles": [
"index.css",
"style.css"
]
}
I'm not sure I want to support this... it would require an exists('index.' + type)
check. I think I'd rather have a proper manifest or no manifest at all.
from duo.
@matthewmueller ok cool, the main: index.css
should do it :) thanks
from duo.
@matthewmueller gahh, nevermind it won't do it because we already have main: index.js
in many of them. any other suggestions?
{
"styles": [
"index.css",
"style.css"
]
}
that wouldn't work because in index.css
you would have @import ./style
and such, which would break component.
from duo.
@lancejpollard duo adds support for:
{
"main": {
"css": "index.css",
"js": "index.js"
}
}
for multi-asset components.
from duo.
@matthewmueller any reason why you don't want that extra exists('index.' + type)
check? it would definitely solve the problem :D
does component support that?
"main": {
"css": "index.css",
"js": "index.js"
}
from duo.
arg, we need more docs haha. ian simplified / improved the docs a lot, but we also lost a bunch of info. that was originally in the components section of the docs. going to add a "creating a duo component" section.
from duo.
I think the main
hacks won't solve the problem here because changing the main to anything other than a single .js
file string will break for component?
It seems like there isn't a simple workaround for these, so maybe we should add support to Duo core to properly create an @import
-ing file from the .styles
array instead?
from duo.
oh yah, good point. yah i don't think there's a great way to add support for both :-/
from duo.
alright i guess for now we'll probably just fork duo and go from there. would you accept a pr or no you don't want to support this? basically it doesn't seem there is anyway we can both use duo and component at the same time while we refactor/port stuff over without this.
some other workarounds other than forking duo are:
- creating new repos for every css component (which isn't really feasible)
- going through all the current css components and locking their versions for component, and then going through all repos using those and tie them to those components (but that would take far too long, probably a few weeks, so it's not worth it)
- write some script that does some tricks where, after duo downloads all components, it goes through and looks for
index.css
in each component, and then rewrites the component.json so it points to that now instead ofstyle.css
. this might work because for the current project we would be using duo, but it's also super hacky (and we'd have to do it this way until every old project was moved off of component)
from duo.
Would the exists check fix it? Basically the order of preference would be:
- try to load from
"index." + type
- try to load from manifest
I just wonder if it's a good idea to ignore the manifest if it's there. As I've mentioned a few times before, the logo
components are the only public repos that I know of that would need to be updated.
The only components that need to get updated are the CSS components that have CSS dependencies. Do you guys have a lot of them?
from duo.
@matthewmueller is there a way we can maybe make a plugin or something to hack around this?
from duo.
@matthewmueller I guess what's partly confusing for me is why you're supporting the manifest for CSS at all? The way it works now it pretty much doesn't work for any of the components we have other than the simple ones that have index.css
and no dependencies. We have many CSS components that have more than 1 file, and usually they're structured (for whatever reason) like this lib/index.css, lib/some-other.css
, and styles[0] = lib/index.css
. But we can't port these to duo, and at the same time support component.json, because we can't add @import
statements to lib/index.css
without it breaking component.
What I'm saying is, styles[0]
is only there to support existing components, but it actually doesn't support the existing component way of doing it (which we're seeing in all these blockers I've been running into). So component should update everything to index.css
, and in the meantime we can have a fallback to styles[0]
for them, rather that making that first-class and index.css
second class.
from duo.
Okay, haha. Umm... yah actually you might be able to:
duo.use(function(file, entry) {
if ('css' != file.type) return;
if ('css' != entry.type) return
var json = require(join(dirname(file.path), 'component.json'));
if (!json.styles || !json.styles.length) return;
for (var i = 0, style; style = json.styles[i++];) {
file.src = "@import " + style + ";\n" + file.src;
}
});
This is untested, haha. But that should get the point.
from duo.
@lancejpollard the CSS manifest is for new components, not old ones. Duo has a much more powerful CSS component system now, as it will only include the stuff that you need, just like JS and it will also respect order:
index.css:
@import "normalize.css";
@import "grid";
// ...
component.json:
{
"name": "css-component",
"dependencies": {
"necolas/normalize.css": "*",
"some/grid": "*"
}
}
Using the component:
@import "matthewmueller/css-component";
from duo.
@lancejpollard try and get the plugin working, if you have any questions let me know. I can take a crack at it too. It will be important for the transition.
from duo.
@matthewmueller for sure, that totally makes sense. That's how we've been doing it definitely.
But right now, here's the order of precedence. Here's an existing CSS component
{
"main": "index.js",
"styles": [
"lib/index.css",
"lib/form.css",
"lib/form-legend.css",
"lib/form-input.css"
],
"dependencies": {
"org/form": "*", // which requires normalize.css, perhaps
"org/input": "*"
}
}
Porting to duo you make it like this (same component.json, but just new index.css
):
{
"main": "index.js",
"styles": [
"lib/index.css",
"lib/form.css",
"lib/form-legend.css",
"lib/form-input.css"
],
"dependencies": {
"org/form": "*", // which requires normalize.css, perhaps
"org/input": "*"
}
}
@import './lib/form';
@import './lib/form-legend';
@import './lib/form-input';
@import 'org/form';
@import 'org/input';
It should work like this imo:
- check
index.css
, if there then load that - otherwise check
styles[0]
. but, that wouldn't even work for a component like that (which is another reason whystyles[0]
shouldn't be first. Really, it should dostyles.map()
type thing to support existing components.
Basically, duo isn't currently supporting existing components anyways, so might as well change the order of precedence.
from duo.
kk will try the plugin method
from duo.
ah yah, i think we can get that working. here's more docs on duo#use
:
https://github.com/duojs/duo/blob/master/docs/api.md#duousefngen
from duo.
Related Issues (20)
- Potential problem with includes (using new cache system) HOT 1
- add the oldest node version supported HOT 3
- Backslash urls when using duo on Windows HOT 1
- Duo tries to resolve files with dots as remotes
- Error when passing empty string into .entry() HOT 3
- Unable to install duo; failed to fetch vargs from registry HOT 4
- Install seems to fail with iojs@3 HOT 5
- importing a directory that does not contain an index.{ext} file gives a nondescriptive error
- Request: Option to flatten build files without Common.JS-like functionality HOT 2
- Install error HOT 1
- Duo not importing a repo with a component.json HOT 6
- Watch problem HOT 1
- Allow required packages to specify their own transform rules
- not helpful "EISDIR: illegal operation on a directory, read" errors
- Duo Build Error HOT 2
- bitbucket instead of github? HOT 1
- cant npm install duo@latest
- error during installing Emscripten box2d HOT 2
- duo: command not found
- duojs.org HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from duo.