Foundation-sites: discussion: v7

[DanielRuf]

Description

Foundation v7 will likely be a monorepo and contain different packages. Compiler, design system, theme & customizer, the different components, plugin system.

We might also create codemods for easier migration of a few things plus some foundation-migrate.js which outputs console information for migrating current code.

Possible Solution

• building-blocks
• cli
• compiler
• core
• components
• customizer
• design-system
• plugin-system
• sass-library
• template-*
• theme

Some compiler like svelte or stencil. We will use yarn workspaces probably or lerna with yarn and a rolling SemVer release process.

https://github.com/semantic-release/semantic-release

• releases: semantic-release
• repo structure: monorepo (lerna with yarn)
• versioned docs: docusaurus
• kitchensink, examples: storybook (plus https://github.com/panosvoudouris/storybook-addon-versions)
• videos: remove
• tests: jest with puppeteer
• IE support: drop
• publish: only npm
• JavaScript: pure ES6 - migrate away from jQuery

Checklist

• [x] I have read and follow the CONTRIBUTING.md document.
• [x] There are no other issues similar to this one.
• [ ] The issue title and template are correctly filled.

[SassNinja]

@DanielRuf do you already have a solution in mind for managing the packages? maybe lerna?

[DanielRuf]

I propose lerna with yarn.

[DanielRuf]

I think we can already experiment with the new monorepo and move some current parts to it (plugins for example).

[paulfelton]

Has anyone considered whether it might be possible to generate web components as a target for foundation's components? Or stencil components that could be transpiled?

This could make it easier for components to be versioned individually, and incorporated in the end-designer's design systems (regardless of the technology they base it on). Likewise for the developer, they could use the components regardless of whether they're generating an Vue, Angular, React (to a certain extent) or vanilla site?

[DanielRuf]

Has anyone considered whether it might be possible to generate web components as a target for foundation's components? Or stencil components that could be transpiled?

This is one of our plans.

[DanielRuf]

I added the link to semantic-release.
In the future we should publish only on npmjs (and additionally on GPR) - GitHub Package Registry).

Other frameworks and platforms can and should consume npm packages or unpkg files.

[paulfelton]

Out of curiosity, do you have a roadmap to version 7, or aspirations? I've seen the project board.

[DanielRuf]

@paulfelton we had a small one but I would say we should revise / update it.

https://github.com/foundation/foundation-sites/wiki/Project-Roadmap

[DanielRuf]

@joeworkman to which platforms do we currently / until now publish to? I want to check if and how they can consume npm packages and if we can publish only to npmjs in the future.

Bower for example registered the old foundation-sites package to the zurb organization.

[joeworkman]

We will definitely start to organize our thoughts around F7 very soon. It will be a lot of work and hopefully we can get more awesome devs to contribute.

@DanielRuf Right now I only publish to NPM and RubyGems. We used to publish to meteor but that was stopped a long time ago. For F7, we can probably pair that down to just NPM.

As for the npm organization. I sent their support team multiple requests and never heard back. For F7, it would definitely be nice to have our own org. I will keep pestering them. Now that they are ran by Github, it may be easier.

[joeworkman]

This issue has been mentioned on Foundation Open Source Community. There might be relevant details there:

https://foundation.discourse.group/t/foundation-and-css-variables/2469/4

[Geddo]

css-variables would be awesome. I integrated it for a bunch of objects like this:

_settings.scss:
:root{ --current-color: var(--primary-color, var(--default-color,#FF0000)); }

So if the css-variable --primary-color is not set, I use the default color #FF0000 for it. For all other elements which should use the new css-variable I created a mixin then like this:
.header { background: $primary-color; @include colorfrompage("background-color"); }

or like
.h1{ @include colorfrompage("color"); }

And this is my simple mixin:
@mixin colorfrompage($property) { transition: all 0.25s; #{$property}: var(--current-color); }

So with that I can easly set a new primary-color via a css-variable in my pages head and with additional scripts like swup.js I get smooth page and color transitions :-)

[joeworkman]

CSS custom properties are definitely something that we want in v7. I have already started a modified version of v6 that supports them already. Although, it’s just a proof of concept. A big change like this should happen in v7.

[ettoredn]

If I may suggest:

1. focus on the grid system / SCSS framework and release an early version with that only
2. drop as many plugins as there are already well working alternatives for them
3. build the remainder plugins as reusable web components using StencilJS and TypeScript

[dlewand691]

For consideration, using CSS variables, this technique looks pretty intriguing as a way to write less code.
https://propjockey.github.io/css-media-vars/

[joeworkman]

I actually already have a build that uses CSS variables. Its not perfect but it's definitely the way to go moving forward. The side effects is that we cannot use Sass color math for many things when using CSS variables. But a lot of effects can be achieved with CSS filters and other modern css techniques.

[paulfelton]

I'd vote for stenciljs too, possibly then documenting with Storybook

[DanielRuf]

1. We schedule a date sometime around the end of august or september for an open zoom meeting that meets on a regular basis with an agenda.

Who is "we"? Currently only Joe and I are actively working on Foundation.

1. We publish steering meetings to youtube just like Node does.

Much effort and work for such a small project in my opinion.
In general we already have a roadmap for a long time. But no time besides work and other projects.

1. We start a private monorepo until alpha that is invite only to people on the steering committee.

Not a good idea, development will be always in the public. No private repos and no invite only stuff.

1. We solidify our build process, CI

Both work, I see no reason to change anything.

Not sure but most of these points are either not relevant, need more active contributors or repeat what we already have in the roadmap and in the relevant issues.

[DanielRuf]

Also it just took over a month to publish a simple fix to the CLI

Please keep in mind that Joe and I do this in our free time and for free. Just saying.

[DanielRuf]

The whole point of what I'm suggesting is to be constructive and help get more active contributors and re-engage the community so that rather than building out features on a roadmap others suggested and abandon, we take a fresh look and start with DOING it. Nothing about your comment is constructive to your own end goals.

To be honest, what would help us at the moment would be to have more reviews on open PRs, PRs for open issues and issues resolved so we can make a clear cut and start the work on v7. Nothing against you or others, there is just still much to do before we can move on. And to decide. And most things are already decided on the original roadmap + some decisions and ideas mentioned here. Ideas are very welcome but I know that most of the volunteers can and will not attend such meetings - we tried that in the pst with all Yetinauts and it didn't really work.

If you want to organize this (date, time, people, accounts, ...) you are very welcome to do so and help usw. I do not have the time for this and I speak from my past experience (Nodejs org, Foundation and others) and it's not that easy.

[DanielRuf]

Honestly, why would I even want to submit a PR

PRs are always reviewed when I find some time. And we merged some in the last weeks. We have to get the other projects forward too (Foundation emails got some new releases, you might have noticed that).

[DanielRuf]

This is why I've maintained my own internal branches of foundation for sites, email and the cli for the last 3 years rather than submitting a PR.

Gatekeepig will not help us at all to bring this forward togehter. I propose you submit some PRs, we check if the proposed changes would be good and we can plan them for the next releases.

[DanielRuf]

As for PR's I'd be happy to review existing PR's test them and either close them or recommend a merge. But if you are looking for new PR as they relate to foundation/foundation-sites/milestone/40, that's not something I can commit to, Trust me, if I could commit to them, I would.

We welcome reviews and contributions for current and new PRs too. You do not have to contribute new PRs if the issues are too complicated / not that easy to solve.

We all have other priorities at work and at home but I don't believe that PR's or the lack there of should roadblock implementing V7 after a 3 year delay...

Well, users of the other projects ask also for updates so we fight on multiple fronts. Like I wrote, Foundation Emails got a few new releases and other projects too. We should resolve the big issues there before we move on - especially as it makes not much sense to open a big new project (v7) and directly drop support for v6 (with such few active people helping with the current tasks).

And I'm also active in other projects so I can not invest so much of my free time.

We had I think 10+ volunteers on the conference calls for foundation 6 alpha, etc.

Currently all other Yetinauts are not actively involved anymore since the move to a community project. Maybe you might have a better connection to them.

When I joined Nicolas tried to do these meetings but after a while we stopped doing them because no one joined or had time.

[ettoredn]

I have been wondering: why nobody is interested anymore in Foundation? Are better alternatives out there? Does anyone need a CSS grid framework anymore?

Don't tell me Bootstrap is an alternative. Bootstrap is trash.

[ettoredn]

Am I wrong in stating that Bootstrap is more oriented towards prototyping while Foundation is about building actual sites?

What are the exact use cases Foundation is supposed to help with?

[ettoredn]

In other words it's in an awkward transition between web pages being the standard and the new web standard of web components.

I wouldn't go as far as calling it a transition. WC fit enterprise design systems well, but I'm not so sure about small and mid size projects. I'm trying to use them through StencilJS right now on a project, and unless you just go full framework like Angular/React (by this I mean you make everything a component because why not), design choices (what should this component do? what should be componentized and what not?) are not so clear, so far.

Case in point: try to use shadow DOM and use Foundation's grid (and the grid only via @include) in multiple component.. Look at that, so many duplicated CSS. Very nice for page performance. _The result is that you basically have to forget about shadow DOM_, which questions the need to use it in the first place, that is unless you have enterprise like design systems.

[pboling]

I have a very narrow comment on the mono repo idea. Want to make sure that having separate repos for plugins is given full consideration. Generally the benefit would be forcing a first-class plugin system, which both official and third party plugins must use. Keeping the plugins inside the mono repo might discourage third party development, or prejudice the tooling in ways that make it more difficult to use a third party plugin than a built-in.

This comment may be quite irrelevant though, given how little I know of the plugin architecture, and having the official plugins developed as part of a holistic core release is also appealing.

Thanks for building Foundation! If my dev path had turned down the front end road I'd be jumping in to help more.

[Baggio89]

Count me in... im with Foundation for 6+ years now. Can help with different things... experience: js, jquery, es(x), css, sass, html, float-g, flex-g, css-g, npm, yarn, node, webpack, wordpress, php, and many more. There must be something i can do 💯 .

Let make this Christmas a good one :)