Macro-schema default values are not rendered in SDL, this can be seen here https://github.com/absinthe-graphql/absinthe/blob/master/test/absinthe/schema/sdl_render_test.exs#L191 and the SDL without the default here https://github.com/absinthe-graphql/absinthe/blob/master/test/absinthe/schema/sdl_render_test.exs#L244

For SDL schema's it does work. This is because SDL's schema's populate the default_value_blueprint and the default_value fields on the%Absinthe.Blueprint.Schema.InputValueDefinition{} struct. The macro-schema only populates the default_value fields. The SDL rendered expects the default_value_print to be present to render the default value for an argument.

I think we could add a schema phase to populate the default_value_blueprint when it's nil, i.e. when it is a macro schema. The SDL renderer will render the defaults correctly then.

Also, note that the default values are not validated currently, arg :public, :boolean, default_value: "some value" will not error during schema compilation.

Thank you!

Some tests could be marked as async to speed up the test suite a little :)

In Elixir master it reports the async and sync test durations.

Finished in 11.5 seconds (8.6s async, 2.9s sync)

Some tests could be marked as async to speed up the test suite a little :)

In Elixir master it reports the async and sync test durations.

Finished in 11.5 seconds (8.6s async, 2.9s sync)

Fixed in v4.0.0-canary.20

It's a big task, it will involve adding the Language and Blueprint extension structs, then using a phase to merge them in when the final schema is being generated.

Thanks @adamalston !

@edolix I did not. Still using the workaround above:

I put the open graph tags in public/index.html as a workaround although I would prefer to have them in my JavaScript files so that I can change them as needed. I looked around for other packages but was unable to find any.

My second attempt was to add the custom rules below under webpackconfig.module.rules. Updated mini-css-extract-plugin from 0.9.0 to 1.3.4. I have this setup working in a basic react/webpack project. But it breaks when starting the app.

      {
        test: /\.css$/,
        use: [
          MiniCssExtractPlugin.loader,
          {
            loader: "css-loader",
            options: {
              importLoaders: 1,
            },
          },
          "postcss-loader",
        ],
        exclude: /\.module\.css$/,
      },
      {
        test: /\.css$/,
        use: [
          MiniCssExtractPlugin.loader,
          {
            loader: "css-loader",
            options: {
              importLoaders: 1,
              modules: true,
            },
          },
          "postcss-loader",
        ],
        include: /\.module\.css$/,
      },
      {
        test: /\.scss$/,
        use: [MiniCssExtractPlugin.loader, "css-loader", "sass-loader"],
      }

Yes, worked

It worked with 4.44.1 before?

On Fri, 15 Jan 2021 at 15:47, Luke Rocco notifications@github.com wrote:

Just a sidenote, I created a new app using 4.0.0-canary.19. It comes with webpack 4.44.1

After updating to webpack 5.14.0, styles stop working. Adding custom loaders in razzle.config or using razzle-plugin-scss, but still not getting it to work.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/jaredpalmer/razzle/issues/1187#issuecomment-760983884, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAADGXEUPRO5GFCN7IMH5TS2BIPVANCNFSM4KP5ZJUQ .

-- Øyvind Saltvik

Just a sidenote, I created a new app using 4.0.0-canary.19. It comes with webpack 4.44.1

After updating to webpack 5.14.0, styles stop working. Adding custom loaders in razzle.config or using razzle-plugin-scss, but still not getting it to work.

Hey!

For those, who cannot / don't want to use v9 beta, I made up with a workaround that works out.

<Spring config={{ duration: 1 }} />

Then you don't use immediate but you achieve the same behavior. And the bug is gone.

Of course, again, it's a WORKAROUND :)