Fable: A common set of configuration files for Fable projects

[alfonsogarciacaro]

@whitetigle has brought up a common issue Fable users are facing and templates or scaffolds don't solve: it's difficult to update Fable when this also involves a configuration change. Right now I put these config changes in Fable.Template but it's likely the users have also changed their configuration files so getting which part they actually need to update is not trivial. This problem is aggravated because we have multiple templates and they update at different rates so users don't know which one they should use as reference.

Inspired by @whitetigle suggestions, to solve this problem I propose:

• Be more opinionated: so far we've tried to give freedom to developers (npm or yarn, webpack or rollup, etc). Now the community is growing and showing their preferences so it's probably the right time to focus on the tools used by most people (and let advanced users make their own changes if necessary): Yarn, Webpack with HMR, Elmish, Fulma, SASS... (I would focus on web development first and in a second phase we can also include mobile development).
• Have standard config files: well basically webpack.config.js, the idea would be to have a super webpack.config.js with switches for different options that users wouldn't need to touch, and then another simple file (fableconfig.js?) to set custom options (like the path to the main project). So whenever we decide to update the common webpack.config.js file (for example, to use babel-env), users only need to drop the new version into their repos (there could even be a command for that).

But we also have to make some decisions:

• To FAKE or not to FAKE?: Currently some templates and others do not. Although I love FAKE and I use it for all my projects, I think it's not necessary for most frontend-only Fable projects (but that's only my opinion) and my main concern is it entails a considerable cognitive load for new F# users. But see also two points below.
• Do more with package.json scripts?: Currently we recommend users to install npm and nuget packages separately, then move to src folder and invoke Fable. However it's possible to reduce the commands using package.json scripts (for example, postinstall to automatically call dotnet restore after yarn installation). We briefly discussed about that before and decided not to do it in order not to hide too many things from the user. But now I find myself using the package.json scripts in my projects instead of calling dotnet restore and dotnet fable directly, so maybe it's a good idea to extend this to other fable projects.
• Frontend only or Fullstack?: Should we consider also server development (for example, that would affect the decision whether to use FAKE or not)? In that case, we should probably just join forces with the SAFE_stack. However, for simplicity I think it may be good to focus on Frontend development and just make sure SAFE_stack becomes a superset, so the work done to standardize Fable projects is also used there by filling the missing parts (server code, deployment scripts...).

What do you think?

@MangelMaxime @forki @Krzysztof-Cieslak @enricosada

[forki]

I personally think this should be decision more in projects like safe
stack.

Am 03.12.2017 01:51 schrieb "Alfonso Garcia-Caro" <[email protected]

:

@whitetigle https://github.com/whitetigle has brought up a common issue
Fable users are facing and templates or scaffolds don't solve: it's
difficult to update Fable when this also involves a configuration change.
Right now I put these config changes in Fable.Template but it's likely the
users have also changed their configuration files so getting which part
they actually need to update is not trivial. This problem is aggravated
because we have multiple templates and they update at different rates so
users don't know which one they should use as reference.

Inspired by @whitetigle https://github.com/whitetigle suggestions, to
solve this problem I propose:

• Be more opinionated: so far we've tried to give freedom to
  developers (npm or yarn, webpack or rollup, etc). Now the community is
  growing and showing their preferences so it's probably the right time to
  focus on the tools used by most people (and let advanced users make their
  own changes if necessary): Yarn, Webpack with HMR, Elmish, Fulma, SASS...
  (I would focus on web development first and in a second phase we can also
  include mobile development).
• Have standard config files: well basically webpack.config.js, the
  idea would be to have a super webpack.config.js with switches for different
  options that users wouldn't need to touch, and then another simple file (
  fableconfig.js?) to set custom options (like the path to the main
  project). So whenever we decide to update the common webpack.config.js file
  (for example, to use babel-env), users only need to drop the new version
  into their repos (there could even be a command for that).

But we also have to make some decisions:

• To FAKE or not to FAKE?: Currently some templates and others do
  not. Although I love FAKE and I use it for all my projects, I think it's
  not necessary for most frontend-only Fable projects (but that's only my
  opinion) and my main concern is it entails a considerable cognitive load
  for new F# users. But see also two points below.
• Do more with package.json scripts?: Currently we recommend users
  to install npm and nuget packages separately, then move to src folder
  and invoke Fable. However it's possible to reduce the commands using
  package.json scripts (for example, postinstall to automatically call dotnet
  restore after yarn installation). We briefly discussed about that
  before and decided not to do it in order not to hide too many things from
  the user. But now I find myself using the package.json scripts in my
  projects instead of calling dotnet restore and dotnet fable directly,
  so maybe it's a good idea to extend this to other fable projects.
• Frontend only or Fullstack?: Should we consider also server
  development (for example, that would affect the decision whether to use
  FAKE or not)? In that case, we should probably just join forces with the
  SAFE_stack. However, for simplicity I think it may be good to focus on
  Frontend development and just make sure SAFE_stack becomes a superset, so
  the work done to standardize Fable projects is also used there by filling
  the missing parts (server code, deployment scripts...).

What do you think?

@MangelMaxime https://github.com/mangelmaxime @forki
https://github.com/forki @Krzysztof-Cieslak
https://github.com/krzysztof-cieslak @enricosada
https://github.com/enricosada

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fable-compiler/Fable/issues/1281, or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNE1Nyl4wNYVHj1VHWaJwr9EmxsHJks5s8fCWgaJpZM4QziOz
.

[whitetigle]

Be more opinionated

Definitely.

Have standard config files

100% agreed

To FAKE or not to FAKE?

I do use FAKE nowes pecially on my Suave based projects. So I agree with you that's really more convenient for projects that need fullstack like SAFE_stack

Do more with package.json scripts?

YES! I think it would allow to appeal even more to the JS community. So that dotnet commands would appear just like any other command that could come from node based tools.

Frontend only or Fullstack?

Well like @forki I think it would depend on the maintainer of the projects. Now enforcing the SAFE_stack for fullstack project could be a good move.

[forki]

Safe stack is basically the idea to create packages that come with common
settings.
Latest safe stack template comes with option for fulma. We will create one
that switches giraffe for suave. Please join this efforts. We can make this
really great

Am 03.12.2017 11:21 schrieb "Whitetigle" [e-mail]:

Be more opinionated

Definitely.

Have standard config files

100% agreed

To FAKE or not to FAKE?

I do use FAKE nowes pecially on my Suave based projects. So I agree with
you that's really more convenient for projects that need fullstack like
SAFE_stack

Do more with package.json scripts?

YES! I think it would allow to appeal even more to the JS community. So
that dotnet commands would appear just like any other command that could
come from node based tools.

Frontend only or Fullstack?

Well like @forki https://github.com/forki I think it would depend on
the maintainer of the projects. Now enforcing the SAFE_stack for fullstack
project could be a good move.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fable-compiler/Fable/issues/1281#issuecomment-348754248,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNPtIoj30cpI6-BCgJyr4sug9H6CNks5s8nZAgaJpZM4QziOz
.

[alfonsogarciacaro]

I've been thinking about this and came to the conclusion the biggest issue here is the webpack.config.js file, and came up with a less controversial way to _hide_ it. I'll try to post something so you can check how it would look and give your feedback.

[alfonsogarciacaro]

We could also take an approach similar to react-scripts: https://github.com/firstlookmedia/react-scripts

[whitetigle]

So it would be:

npm start
npm build
npm test

something like that?

[alfonsogarciacaro]

I was thinking of yarn to install dependencies (both npm and Nuget), yarn start for development and yarn build for production, which should probably include testing. Though we still need to define our _standard_ test tools ;)

[whitetigle]

Well three commands to rule them all then? I'm in! 👍 😉

[alfonsogarciacaro]

To be continued in the fable-scripts repo 😸