roadmap to 3.0

[threepointone]

3.0 will be a major rewrite, possibly breaking some apis. Keeping this issue open for thoughts and plans. Feel free to contribute.

• setting a goal of halving the size of the lib (so from ~8k to ~4k), might fall short
• tree shaking friendly, so it might even all reside in just one file

css

bread and butter function, consolidating previous api set.

css(...obj)
css`...`

css.keyframes(spec)
css.fontFace(spec)
css.global(selector, obj) / css.insert(string)

// ssr 
renderStatic(fn:() => html)
renderStaticOptimized(fn:() => html)
hydrate(ids)

• whether classes and / or data attributes get added to the stylesheet should be plugin driven
• on that note, the plugin system should get an overhaul, exposing more of the innards, at different points.
• this will also have the side effect of making the overall css cleaner
• we currently do one level of nesting, maybe we can consider infinite? what would it look like?

deprecate / external modules

• simulations, labels as plugins
• aphrodite, jsxstyle interfaces
• react/createElement
• glamor/ous
• reset

[to be continued...]

[vdanchenkov]

Will result value act as component to gain parity with styled components? 😉

const Component = style = css`...`
const Result = () => <div>
   <div {...style}></div>
   <Component/>
</div>

[threepointone]

No, but I'm working on a separate module for parity with SC, will probably mimic the styled.tag api. Will get to it after getting the tagged css literal to a stable place.

[threepointone]

as of 2.20.x, much of the the above is live, and the docs and such have been reflected to show the same. for the migration to v3, there are 3 big ticket items -

• moving /react, /aphrodite etc to their own modules, glamor-*
• proper es6 builds etc for all of them
• glamor-legacy as an alias to the older interface, inclusive of everything. (probably non tree-shaking friendly)

[ianstormtaylor]

Just wanted to say that I'm really excited to see all of the extra stuff moved out of core 👍

From an outsider's point of view, it's currently hard to tell what Glamor wants to be, or where some of the current extra features/docs add value. Makes it harder to judge whether to depend on it longer term. It seems like the main core that you're working towards is really what matters, and the others are just experiments to prove that it's flexible, but they don't seem like things that will actually be depended on.

[vkbansal]

Need help with these tasks? I'm in.

[donaldpipowitch]

@threepointone Besides adding Lerna with #195, would you be open to switch the code base to TypeScript given more recent issues like #196 and #197 and the older #11? @otbe and I could probably do this after we reviewed and merged #195?

[axross]

Now, many packages written in TypeScript are published in npm.
I wanna help if new code base has written in TypeScript!

[donaldpipowitch]

@threepointone Can @otbe and I mess around with your v3 branch? And geht rights to publish new npm versions?

We'd like to

• create a new v3 branch starting with #195 as a base
• switching to TypeScript
• use css as the "bread and butter function, consolidating previous api set" as mentioned in your first post
• enhance test coverage
• make a new v2 release with deprecation warnings (e.g. "Use glamor-reset instead of glamor/reset.", "Use css() instead of merge()." and so)
• make a v3 prerelease
• write a migration guide from v2 to v3

[ChristopherBiscardi]

@donaldpipowitch is there anything that other functions can do that css can not? I am under the impression that all we need to do is add the deprecations in that case.

Ex: merge and style are already defined as css.

[donaldpipowitch]

is there anything that other functions can do that css can not?

I don't think so. I guess a deprecation for other functions in v2.x is everything we need.

[threepointone]

@donaldpipowitch sorry for the delay -

• typescript sounds great! please be ready to answer stupid questions from me :)
• the rest sound great too.

this seems like a lot of work, so please do it incrementally, one by one. we'll do releases at each delta, I'm fine with that.

[threepointone]

I'll give pub access to the two of you later today

[threepointone]

@donaldpipowitch @otbe what are your npm usernames?

[donaldpipowitch]

"donaldpipowitch" and "otbe" :D thank you!

[threepointone]

done

[donaldpipowitch]

❤️

[donaldpipowitch]

I'll create a separate issue for every step pointed out in #83 (comment). Every step will be a separate prerelease alongside with deprecation warnings and a migration guide. I create a separate issue for every deprecation so I can easily log a link to the specific issue with more information inside the console.

[donaldpipowitch]

glamor currently exports a presets object containing preconfigured media queries. I probably would like to remove this from v2 to v3 as I don't think this is needed in the core package and more suited for some utils package or a bigger ui framework based on glamor.

What do you think?

[esamattis]

As author of a library building on top of glamor I'd would prefer the glamor core to not have any opinions like predefined media queries, css resets. Just an awesome raw js-in-css engine.

Btw, I have feature request: Option to disable autoprefixer. Devtools inspector is quite messy when every rule is prefixed. It would be nice to disable it for development sometimes.

[ChristopherBiscardi]

@epeli prefixing is just a default set of plugins. You can reset all plugins by running plugins.clear() or remove a specific one by using plugins.remove() as mentioned in the docs.

import { css, plugins } from 'glamor';
plugins.clear();

[ChristopherBiscardi]

@donaldpipowitch I agree on removing the preconfigured media queries from core. glamor-ous already defines some media queries of it's own.

[donaldpipowitch]

Ladies and gentleman! We have our first prerelease 🎉

$ npm i glamor@next
glamor@3.0.0-1

$ npm i glamor@latest
glamor@2.20.24

Everything seems to worked fine. Only glamor-utils threw an error: #215

[threepointone]

Just fantastic! Congrats!🎈🎊🍾🎉

[kentcdodds]

Hi friends! 👋 just curious to hear a status update on this and what I could do to help 3.0.0 go to latest :)

[threepointone]

Well... I'd love to get some feedback from at least one person on how v3 worked out for them :) it seems fairly stable otherwise.

[kentcdodds]

I'm working on something right now for my app where I think glamor/glamor-styled/glamor-jsxstyle would really help. So I'll give v3 a try and report back :)

[kentcdodds]

After looking at it for a little bit it's not quite what I'm looking for, so I'm going to continue with my own thing (still building on glamor though!)

[threepointone]

Let us know how it goes! Happy to help

[ChristopherBiscardi]

I think one of the powerful things about glamor is it's ability and inclination to support multiple surface APIs (Aphrodite, JSXStyle, StyledComponents, etc). Please do let us know how it goes @kentcdodds :)

[donaldpipowitch]

I created a new issue for the changes I think which qualify for the next possible prerelease step: #229. As introduced in the first post of this issue the API surface should be reduced for v3. Now we need to specify what should be deprecated exactly. I'd like to move this discussion to #229 and started with the question: Should every API mentioned in helpers.md be deprecated? I think everything mentioned there can be achieved with css, too.

[donaldpipowitch]

In #231 @ChristopherBiscardi proposes to

1. deprecate glamor-jsxstyle in favor of glamorous
2. rename glamor-ous to glamor-skeleton to avoid confusion with glamorous and because it is based on http://getskeleton.com/

I think both points are good ideas and looking at @kentcdodds reactions he thinks the same ;)

Both points can be discussed here and if no one has objections I'd do that after #229.

[kentcdodds]

Sounds great to me! Thanks!

[dzearing]

Any updates on 3.0 progress?

[donaldpipowitch]

Yeah, the most recent PR is here: #269 👍

[threepointone]

closing this, will reopen a new issue later with changed plans. for now v2 is the way to go.