profile
viewpoint
Jeremy Albright Js-Brecht Oahu, Hawai`i IT Specialist with a background in - network systems/dba & development - systems software engineering - web development

Js-Brecht/gatsby-plugin-ts-config 24

Configure Gatsby to use typescript configuration files

Js-Brecht/gatsby-plugin-pnpm 12

Provides PNPM compatible module resolvers to Webpack for Gatsby

Js-Brecht/gatsby-plugin-atl 3

Awesome Typescript Loader for Gatsby

Js-Brecht/babel-plugin-module-resolver 0

Custom module resolver plugin for Babel

Js-Brecht/berry 0

📦🐈 The active development trunk for Yarn 2 ⚒

Js-Brecht/DefinitelyTyped 0

The repository for high quality TypeScript type definitions.

Js-Brecht/devcert 0

Local HTTPS development made easy

Js-Brecht/gatsby 0

Build blazing fast, modern apps and websites with React

startedmicrosoft/rushstack

started time in a day

issue commentgatsbyjs/gatsby

gatsby/devcert https fails: Error: "localhost" is not a valid domain name

devcert version 1.1.2 is published. It should fix this issue.

ngmgit

comment created time in a day

pull request commentdavewasmer/devcert

Fix valid domain regex

Welcome back @zetlen! Thanks for the merge :rocket:; I'm sure everybody will be glad.

stramel

comment created time in a day

pull request commentdavewasmer/devcert

Fix valid domain regex

@stramel unfortunately, I don't have write access.

@zetlen I hate to bother you; I'm sure you're busy. This issue really is causing a lot of grief for Gatsby users, though. Would you mind taking a look at this PR so we can resolve these problems?

stramel

comment created time in 2 days

issue commentJs-Brecht/gatsby-plugin-ts-config

Issues with babel-preset-gatsby

Ah, okay, I figured out what was going on with it. The Gatsby dependency version was ^2.0.7. I didn't look to see what the actual version that was resolved by that spec was, but it was way too early. Gatsby didn't support themes & default exports from gatsby-config in themes back then.

Additionally, the configDir from generateConfig() was spelled .gastby, which caused a few more issues. That misspelling is actually very common; I can't count the number of times I've typed it like that, and it's one of those that's difficult to notice unless you're looking specifically for it.

After I fixed those two issues, it seemed like it started to work correctly.

Phil-Barber

comment created time in 3 days

issue commentwithspectrum/spectrum

Post editing issue

The weird-hot-update-err made me chuckle.

Js-Brecht

comment created time in 4 days

issue openedwithspectrum/spectrum

Post editing issue

Issue Type (check one)

  • [x] Bug Report
  • [ ] Feature Idea
  • [ ] Technical Discussion
  • [ ] Question (these will be auto-closed, please ask them on Spectrum instead https://spectrum.chat/spectrum/open)

Description (type any text below)

Trying to edit a post throws some fun errors now:

in Chrome: image

In Firefox: image

created time in 4 days

issue commentgatsbyjs/gatsby

gatsby/devcert https fails: Error: "localhost" is not a valid domain name

For anybody that wants to use their own self-signed certificate to workaround this issue, there’s been several methods described in #14490. For example, see my comment here. Shouldn’t need the NODE_EXTRA_CA_CERTS environment variable anymore, though. That’s been fixed.

Another way was using mkcert, in the comment above mine.

An easier workaround is to add a resolution in your package.json for ”devcert”: “1.1.0”

ngmgit

comment created time in 4 days

issue commentJs-Brecht/gatsby-plugin-ts-config

Issues with babel-preset-gatsby

I’m glad that helped 🙂

Just as an FYI, Gatsby adds babel-preset-gatsby automatically.


There seems to be more gatsby-starter-typescript projects out there than I remember there being before. Can you point me to the one you were using? If there was no export default in the root gatsby-config, then that error may be caused by this plugin. I’d like to see if there’s a good way to fix it

Phil-Barber

comment created time in 4 days

issue commentJs-Brecht/gatsby-plugin-ts-config

Issues with babel-preset-gatsby

It’s because this plugin is spinning up a Babel process for transpiling, which causes it to read your .baberc. babel-preset-gatsby is expecting to be run after bootstrap (during the Webpack phase), but this plugin is running before the bootstrap.

To fix this, you would need to use onCreateBabelConfig to load your .babelrc configurations manually. You could likely store those settings next to gatsby-node (Name the file differently, though!), then read them in and loop over them, adding them to Gatsby using setBabelPlugin and setBabelPreset. This should make the processing automatic, and you can maintain the settings file the same way you would .babelrc.

Out of curiosity, what issues were you having with gatsby-preset-typescript?

Phil-Barber

comment created time in 5 days

delete branch Js-Brecht/gatsby

delete branch : regression-develop-process

delete time in 5 days

issue commentgatsbyjs/gatsby

[gatsby develop] Exiting via Ctrl-C leaves terminal/shell in a bad state (Linux/Mac)

@Korede-TA Okay, this sounds like it's not really related to the original post here; the end result seems similar, but the cause/effect are actually different. It seems like it's more related to the changes made in #22759. I think what you're experiencing really should have its own issue, if you don't mind opening one, because it deserves further investigation. It should get more attention then.

rjray

comment created time in 5 days

issue commentgatsbyjs/gatsby

[gatsby develop] Exiting via Ctrl-C leaves terminal/shell in a bad state (Linux/Mac)

@Korede-TA what version of node are you running?

if i hit ctrl-c to kill the gatsby serve command, it doesn't respond either.

Do you mean that hitting CTRL-C fails to end the process? Or does it successfully end the process and leaves the terminal in an unusable state (output mangled/input hidden)?

One way to test would be to start your process, then do a ps -ef |grep gatsby and take note of your process id (second column). Now, when you hit CTRL-C, go look at the output of that command again, and see if the process is still there.

Another thing you can do, after you hit CTRL-C, type reset and hit enter. See if it restores your terminal.

Does it do the same thing if you use bash or sh? I'm also curious to know if it happens every time you run gatsby develop, or if it's intermittent.

rjray

comment created time in 6 days

issue commentgatsbyjs/gatsby

☂️ [Umbrella issue] Yarn 2 issues

Ahaha... yes, I would love to fix these issues, but unfortunately, I don’t have the time. It would probably be a few weeks before I’d be able to squeeze them in.

ascorbic

comment created time in 6 days

issue commentgatsbyjs/gatsby

☂️ [Umbrella issue] Yarn 2 issues

@barbalex Gatsby is unable to resolve the plugin defined here, because it doesn't keep babel-plugin-styled-components as a dependency (nor should it): https://github.com/gatsbyjs/gatsby/blob/ff4ce023f3714914fecaf15deed185d3c64c52b3/packages/gatsby-plugin-styled-components/src/gatsby-node.js#L10-L18

That would need to be defined with an absolute path, but Gatsby uses that name property for deduplicating/merging settings: https://github.com/gatsbyjs/gatsby/blob/ff4ce023f3714914fecaf15deed185d3c64c52b3/packages/gatsby/src/redux/reducers/babelrc.ts#L51-L69

Something would likely need to be done to preserve that behavior, but still allow for a fully resolved path.

ascorbic

comment created time in 7 days

push eventJs-Brecht/gatsby

Orestis Ioannou

commit sha fac20aec80e7c37c277f739f6d87838952e4ea9a

chore(showcase): Add bold.org into showcase (#25079)

view details

Sidhartha Chatterjee

commit sha b2bf298e15c3bca6d9a3535f22179af003fccaef

feat(gatsby): Instrument partial writes to page data (#24808) * Add a pending page data reducer * Add mechanism to flush page data after collecting pending writes * Linting * Fix * Update snapshot * move to program._ instead of command * do not emit page data in query queue * fix check for develop * add a null check * Prevent flush races * Only flush if in queue * Enqueue instead of flushing * Linting * Make enqueue not await * Reset enqueue * Update packages/gatsby/src/commands/build.ts Co-authored-by: Michal Piechowiak <misiek.piechowiak@gmail.com> * Linting * immediately flush on build * Add a getter * Move page data back to TS * Use named imports for page data * Use better names * fix typings and remove async Co-authored-by: Michal Piechowiak <misiek.piechowiak@gmail.com>

view details

Nat Alison

commit sha d556fe3e140adee14359c26cb47ca3629a4f6dac

maintenance(www): add environment variables to disable sourcing from docs/plugins (#25080)

view details

Matt Kane

commit sha 0407cc66f80a97ccb325b93331e60fc219b142aa

perf(gatsby): Lazily re-create GraphQL runner (#25063)

view details

Ward Peeters

commit sha 4d70f1ac1717fece1b8e1b410ad8823820bd62e7

fix(gatsby-core-utils): fix hash for buffers (#24614) * fix/buffer-content-digest * fix snapshot

view details

Mikhail Novikov

commit sha c884b0dcf049d910991d56e7f6016761f6333487

chore(docs): Update documentation for createNodeField (#24740)

view details

nibtime

commit sha 13aaa16dd9711e517059286224dde9c11ebaa567

fix(gatsby-plugin-offline): versioned import of idb-keyval (#24938) * fix(sw): versioned import of idb-keyval with the version included it is ok to cache it immutable alongside the other fingerprinted js files produced by Gatsby * style: fix linting errors * fix(sw): replace versioned import in sw-append.js

view details

nibtime

commit sha d427663e225209684822314235bfacf83915b8b1

fix(sw): use NetworkFirst strategy for page-data (#24940) * fix(sw): use NetworkFirst strategy for page-data Fixes #24930 * fix(sw): NetworkFirst strategy for app-data.json * fix(sw): StaleWhileRevalidate for page-data and app-data

view details

Luke Xavier Symington

commit sha 8e6e021014da310b9cc7d02e58c9b3efe938c665

fix(gatsby): allow amending autoprefixer options (#24907) * fix(gatsby): allow amending autoprefixer options - Changed types for PostCSS plugins from webpack `Plugin` type to PostCSS `Plugin<T>` type. - Added a check of each plugin's `postcssPlugin` property; a plugin with a `postcssPlugin` property equal to `autoprefixer` will have its options assigned to the default. * fix(webpack): allow amending autoprefixer options - Amended the change to use object spread instead of `Object.assign()`. - Added a test to check that the default options are applied when called with no options. - Added a test to check that when called with options, these will be applied to the defaults and override where applicable. * fix(webpack): allow amending autoprefixer options - Remove unnecessary `expect` clauses. Co-authored-by: Luke Xavier Symington <lxsymington@gmail.com>

view details

Michelle Gienow

commit sha f68cdb798793efff8f80061b9156f1ff2ce13b5a

Add Gatsby CLI Survey second round results (#25096) * Add Gatsby CLI Survey second round results * chore: format * change frontmatter date * remove quotes from frontmatter * Correct typo * chore: format * fix line break * chore: format Co-authored-by: gatsbybot <mathews.kyle+gatsbybot@gmail.com>

view details

Dan Kirkham

commit sha 281c4254ff3bfbdff435a35b492abc7497d0bb2a

chore(eslint-config): change eslint to better match strict ruleset (#24920)

view details

Shane Thomas

commit sha 39d4cec6ff9b3c51f4b71d218c0509fa8081df5a

feat(gatsby-source-drupal): Add skipFileDownloads config option (#25029) * Add gatsby-source-drupal skipFileDownloads config option * Add gatsby-source-drupal skipFileDownloads test * Fix skipFileDownlaods logic error on webhook updates * Add additional gatsby-source-drupal skipFileDownlaods test

view details

LB

commit sha f88d9d8c07434ddf8e9fee477fc52c6e0419a365

manually bump starters to solve problem (#25107) Co-authored-by: Laurie Barth <laurie@LauriesrkLaptop.fios-router.home>

view details

Stafford Rose

commit sha a9e0290db9735872eb32b42e58f2e69bd838fa55

feat(gatsby-source-shopify): Add handle field to blog + article queries (#24766)

view details

Nat Alison

commit sha 6c8ca0ad45c81b8df06fd9d5b84a79eb915a5c93

fix linting in blog post (#25114)

view details

Knut Melvær

commit sha bfbe02a59008bbf0e006b93b12f9921f64a13747

upgrade dependencies (#25117)

view details

Matt Kane

commit sha a78c7b05bf6961f51234ec504b42ac75f06da455

refactor(gatsby): change bootstrap to use services (#24816) * Add typings for action arrays and thunks * Switch back to non-null assertion * Add comment * Refactor bootstrap into services * Use separate gql runner for bootstrap * Import reporter typings * Switch to new bootstrap * Fix imports * Add create pages * Add extract queries * Fix typings * Rebuild schema with sitepage * Rename context vars * Fix types * Update packages/gatsby/src/services/source-nodes.ts More descriptive name Co-authored-by: Ward Peeters <ward@coding-tech.com> * Changes from review * Bikeshed the function name * Better unhandled rejection handling * Update packages/gatsby/src/services/initialize.ts Co-authored-by: Peter van der Zee <209817+pvdz@users.noreply.github.com> * Changes from review * Format Co-authored-by: Ward Peeters <ward@coding-tech.com> Co-authored-by: Peter van der Zee <209817+pvdz@users.noreply.github.com>

view details

Matt Kane

commit sha b95439c0dbce9c1434278a4800b51bed5d17116a

chore(release): Publish - babel-preset-gatsby@0.4.10 - gatsby-admin@0.1.69 - gatsby-cli@2.12.47 - gatsby-core-utils@1.3.6 - gatsby-page-utils@0.2.10 - gatsby-plugin-manifest@2.4.12 - gatsby-plugin-mdx@1.2.16 - gatsby-plugin-offline@3.2.11 - gatsby-plugin-page-creator@2.3.10 - gatsby-plugin-preload-fonts@1.2.11 - gatsby-plugin-sharp@2.6.12 - gatsby-recipes@0.1.41 - gatsby-remark-images@3.3.11 - gatsby-source-contentful@2.3.16 - gatsby-source-drupal@3.5.13 - gatsby-source-filesystem@2.3.12 - gatsby-source-shopify@3.2.12 - gatsby-source-wordpress@3.3.13 - gatsby-telemetry@1.3.12 - gatsby-theme-blog-core@1.5.44 - gatsby-theme-blog@1.6.44 - gatsby-theme-notes@1.3.70 - gatsby-theme-ui-preset@0.0.59 - gatsby-transformer-remark@2.8.17 - gatsby-transformer-screenshot@2.3.10 - gatsby-transformer-sqip@2.3.12 - gatsby@2.23.5

view details

Blaine Kasten

commit sha 4c0916b25b3b1c8758ff33f877f4b588b491ffc7

fix: Several Fixes for Scroll Handling and Restoration (#24306) Co-authored-by: Ward Peeters <ward@coding-tech.com>

view details

Blaine Kasten

commit sha ba0597b4bc6f5c949675992827599feda04be438

chore(release): Publish - gatsby-admin@0.1.70 - gatsby-react-router-scroll@3.0.4 - gatsby-theme-blog-core@1.5.45 - gatsby-theme-blog@1.6.45 - gatsby-theme-notes@1.3.71 - gatsby-theme-ui-preset@0.0.60 - gatsby@2.23.6

view details

push time in 7 days

issue commentgatsbyjs/gatsby

☂️ [Umbrella issue] Yarn 2 issues

@barbalex That is probably the result of transpiling resolve-module-exports.ts to resolve-module-exports.js. Should be able to fix it by moving @babel/types to Gatsby's production dependencies. It will probably also need @babel/runtime moved to production dependencies, eventually. https://github.com/gatsbyjs/gatsby/blob/ff4ce023f3714914fecaf15deed185d3c64c52b3/packages/gatsby/package.json#L156-L159

ascorbic

comment created time in 7 days

issue commentgatsbyjs/gatsby

[gatsby develop] Exiting via Ctrl-C leaves terminal/shell in a bad state (Linux/Mac)

Hmm, gatsby serve doesn't do hot reloading. Do you mean gatsby develop?

rjray

comment created time in 7 days

issue commentgatsbyjs/gatsby

[gatsby develop] Exiting via Ctrl-C leaves terminal/shell in a bad state (Linux/Mac)

@Korede-TA what is it that it’s doing/not doing?

rjray

comment created time in 8 days

startedrustwasm/wasm-bindgen

started time in 12 days

push eventJs-Brecht/gatsby-plugin-ts-config

Jeremy Albright

commit sha 15790af11575cdb3c564133ab161f1ff9a7f112e

grammar

view details

push time in 12 days

issue commentJs-Brecht/gatsby-plugin-ts-config

Handling custom plugins.

@rroslaniec Sorry it's taken me this long to get this finished. Sneaking in the few hours I needed to implement this has been tough.

The new feature is about ready for production; just needs to have a little bit more testing done out in the wild. It is published right now as gatsby-plugin-ts-config@next, which is release candidate 3. I've worked out any issues I could find; I think all that may be left is whatever issues exist under circumstances that I haven't been able to foresee.

There are some changes to the endpoints passed to the gatsby-config function. You can read about it here.

The new API is detailed here, as well as the new type utility here. I have also updated the example to show the usage of the new function here.

Take it for a spin, if you would, and please drop a line about it on #14. If you have any suggestions or encounter any issues, please let me know.

Thanks!

rroslaniec

comment created time in 12 days

PR opened Js-Brecht/gatsby-plugin-ts-config

Custom plugin resolver enhancement

This PR implements a new API: includePlugins. With this function, you can resolve local/vendor plugins before they are given to Gatsby. Resolving plugins this way will also transpile them, if they are Typescript, so that they are ready for consumption.

The type utility used for defining plugin option types, IMergePluginOptions, has been removed. It is now replaced by IGatsbyPluginDef, which can be used in conjunction with includePlugins, to strongly type your plugin options.

The function export from gatsby-node and gatsby-config will no longer accept a second generic type parameter.

Use includePlugins() from now on to type your plugins.


Closes #12

+1801 -891

0 comment

14 changed files

pr created time in 12 days

push eventJs-Brecht/gatsby-plugin-ts-config

Jeremy Albright

commit sha 830e7ad7b50e8b8dea53b9005a346f3128726765

documentation update

view details

push time in 12 days

push eventJs-Brecht/gatsby-plugin-ts-config

Jeremy Albright

commit sha 67efa9d5efc9e437f112bddf74aef7ed50c89299

publish 1.0.0-rc.3

view details

push time in 12 days

push eventJs-Brecht/gatsby-plugin-ts-config

Jeremy Albright

commit sha bf243e3bf907a1f5c461e1f374063df642d0ca7b

custom babel preset

view details

Jeremy Albright

commit sha c5add22d2a30675abd400f1843e7c39a0cb87f3a

resolve gatsby-config first

view details

Jeremy Albright

commit sha 0df829ed75320fd4c693d0f2742e46bfa7f699ba

remove babel-preset-gatsby-package

view details

Jeremy Albright

commit sha 7b6def04f8f42f6494ffdd57709017bb628948ec

fix types for union

view details

Jeremy Albright

commit sha 4e18e75ced2dff2561e04a2924b2727c76375057

use custom babel preset

view details

Jeremy Albright

commit sha b3c0d916c1db19b4df377666863d4c3610d6137d

custom babel preset

view details

Jeremy Albright

commit sha ade950d4b327e9551be0bf5d797cfac9c3989a09

use Module._extensions

view details

push time in 12 days

issue commentdavewasmer/devcert

localhost is not a valid domain name

#57 will fix it

stramel

comment created time in 16 days

issue commentgatsbyjs/gatsby

Page content loaded inside a 'gatsby-announcer' div

It's probably a conflict between SSR and hydration in the client. It may have worked correctly if you had put the <ToastComponent /> in wrapPageElement, and kept everything else in wrapRootElement.

Putting <ToastComponent /> inside of <TemplateProvider /> actually changes how it is called in the transpiled code. What would help is seeing a transpiled version of the React tree, but getting that is not a trivial task, especially because it would be important to see the React tree that is generated during SSR, too.

I think as a general rule of thumb, stuff in wrapRootElement should not change the DOM.

romarybintsev

comment created time in 16 days

issue commentgatsbyjs/gatsby

Page content loaded inside a 'gatsby-announcer' div

It works for me? Did something change?

image

romarybintsev

comment created time in 16 days

issue commentgatsbyjs/gatsby

Page content loaded inside a 'gatsby-announcer' div

For testing, can you try removing ErrorBoundary and ToastComponent?

Is there anything in gatsby-ssr?

What does TemplateProvider do?

I understand not being able to share the repository; that’s pretty common. However, a simplified reproduction helps a great with troubleshooting. Sometimes, just the act of recreating the issue as simply as possible is enough to identify the problem. I have never had this issue, so I’m unable to recreate it myself, and seeing all of the code that is causing the effect is necessary to track down the root cause. There’s a lot of moving parts to consider

romarybintsev

comment created time in 16 days

issue commentgatsbyjs/gatsby

Page content loaded inside a 'gatsby-announcer' div

Need to see the code

romarybintsev

comment created time in 17 days

issue commentgatsbyjs/gatsby

Page content loaded inside a 'gatsby-announcer' div

Can you share a reproduction of the issue?

romarybintsev

comment created time in 17 days

push eventJs-Brecht/gatsby-plugin-ts-config

Jeremy Albright

commit sha 12f9ba76721099e76e188a2827294c1af757e89f

resolvePlugins -> includePlugins verbiage

view details

push time in 17 days

issue commentJs-Brecht/gatsby-plugin-ts-config

Handling custom plugins.

@rroslaniec Okay, I've made a great deal of progress on this feature. I just need to do some testing. I have published a release candidate as gatsby-plugin-ts-config@next, because I'd like to open it up for testing, and it might be another week before I can finish. I don't have time to do it all tonight.


Before I continue, I would like to define a couple of terms:

  • ITSConfigFn: The type utility that defines the function that can be exported from gatsby-config and gatsby-node. It receives the following options:
    • projectRoot
    • configDir
    • cacheDir
    • endpoints
  • endpoints contains an object that looks like this:
    {
      node: string[];
      config: string[];
      plugin: {
        [pluginName: string]: {
          node: string[];
          config: string[];
        }
      }
    }
    
    • The first index of each string[] is the first file... the root gatsby-config or the root gatsby-node for the default site, or the root gastby-config/gatsby-node for each plugin listed. All of the indexes following that is the import chain; all of the modules that are imported by the first, and every successive module.

This is a major version release, because there have been some breaking changes in the public API. Mostly the only thing that was removed was second parameter in ITSConfigFn for the discriminated types for defining plugin options. Because the plugin array needs to accept untyped plugins, that parameter wasn't able to act as an actual discriminated union.

There is now a new export, includePlugins. It can be passed type interfaces for different plugin options as the first generic parameter. It works just like it worked for ITSConfigFn, except now, if you do define them, you won't be able to include plugins without types. You can, however, call includePlugins multiple times if you want to also include untyped plugins.

includePlugins has a couple of overloads.

  • You can define an array of plugins, just like you can for the normal config export, as well as a callback function in the second parameter that takes the same parameters as ITSConfigFn.
  • You can pass only the array,
  • Or, you can pass just the callback function.

The overload looks like this:

    <T extends IGatsbyPluginDef = IGatsbyPluginDef>(pluginsCb: IPluginDetailsCallback<T>): void;
    <T extends IGatsbyPluginDef = IGatsbyPluginDef>(plugins: T[], pluginsCb?: IPluginDetailsCallback<T>): void;

The order of processing is as follows:

  1. The array of plugins for each includePlugins will be resolved in order, and then compiled
    • This means that the resolved endpoints and imports will be passed to the main ITSConfigFn.
  2. The main ITSConfigFn will have all of its plugins resolved
    • The plugins will now have all of their paths resolved before being passed to Gatsby. This fixes an issue with yarn 2.
      • I recently fixed an issue in the themes plugin processing that Gatsby does, so that a theme's plugins could be resolved properly when using yarn 2 or pnpm. That fix breaks this plugin because this plugin would no longer be operating within the scope of the default site, meaning it wouldn't be able to resolve any of your default site plugins. That is a critical failure, with a 100% stop rate. Resolving all of the plugin's before they get back to Gatsby is a pretty solid resolution.
  3. All of the callbacks that were defined in the includePlugins calls will be resolved in the order they were defined.
    • Each time a callback is called, it will receive a fresh/up-to-date list of endpoints. This means that each successive callback will receive all of the resolved plugins, and those plugin's imports, that the last callback generated.

It is important to note that the order of processing is also the order that the plugins will appear in the final result that is fed back to Gatsby. If you have plugins that rely on a specific order, then that must be accounted for.


I am including an example usage below that I used for some preliminary tests. Branch is here. Please let me know as soon as/if you encounter any issues. I will try to wrap this up within the next few days, but it may need to wait until next weekend.

<details> <summary>Example usage</summary>

import { IPluginOptions as IPnpmPluginOptions } from 'gatsby-plugin-pnpm';
import { ITSConfigFn, includePlugins, IGatsbyPluginDef } from 'gatsby-plugin-ts-config';
import { PluginOptions as ITypegenPluginOptions } from 'gatsby-plugin-typegen/types';
import { FileSystemConfig } from 'gatsby-source-filesystem';

includePlugins<
    | IGatsbyPluginDef<'gatsby-plugin-pnpm', IPnpmPluginOptions>
    | IGatsbyPluginDef<'gatsby-plugin-typegen', ITypegenPluginOptions>
    | FileSystemConfig
>([
    'gatsby-plugin-pnpm',
], ({ projectRoot }) => ([
    {
        resolve: 'gatsby-plugin-typegen',
        options: {
            outputPath: `${projectRoot}/.gatsby/graphql/types.ts`,
            emitSchema: {
                [`${projectRoot}/.gatsby/graphql/introspection.json`]: true,
                [`${projectRoot}/.gatsby/graphql/schema.graphql`]: true,
            },
            emitPluginDocuments: {
                [`${projectRoot}/.gatsby/graphql/plugin-documents.graphql`]: true,
            },
        }
    },
    {
        resolve: `gatsby-source-filesystem`,
        options: {
            name: `images`,
            path: `${projectRoot}/src/images`,
        },
    },
]))

const gatsbyConfig: ITSConfigFn<'config'> = ({
    projectRoot,
}) => ({
    siteMetadata: {
        title: `Gatsby PNPM/Typescript Starter`,
        description: `Kick off your next, great Gatsby project with this starter. This starter ships with the main Gatsby configuration files you might need, including support for PNPM and Typescript.  It also includes a file structure that is conducive for developing your Gatsby configuration files with Typescript`,
        author: `@js-brecht`,
    },
    plugins: [
        {
            resolve: `gatsby-plugin-ts`,
            options: {
                codegen: false,
            }
        },
        `gatsby-plugin-tsconfig-paths`,
        `gatsby-plugin-react-helmet`,
        {
            resolve: `gatsby-source-filesystem`,
            options: {
                name: `images`,
                path: `${projectRoot}/src/images`,
            },
        },
        `gatsby-transformer-sharp`,
        `gatsby-plugin-sharp`,
        {
            resolve: `gatsby-plugin-manifest`,
            options: {
                name: `gatsby-starter-default`,
                short_name: `starter`,
                start_url: `/`,
                background_color: `#663399`,
                theme_color: `#663399`,
                display: `minimal-ui`,
                icon: `${projectRoot}/src/images/gatsby-icon.png`, // This path is relative to the root of the site.
            },
        },
        // this (optional) plugin enables Progressive Web App + Offline functionality
        // To learn more, visit: https://gatsby.dev/offline
        // `gatsby-plugin-offline`,
    ]
});

export default gatsbyConfig;

</details>

rroslaniec

comment created time in 17 days

push eventJs-Brecht/gatsby-plugin-ts-config

Jeremy Albright

commit sha fe8d50ef1d472e9f1e7acd9ac61d191991aa02fc

`includePlugins` feature

view details

Jeremy Albright

commit sha 7c8112f01b22a1b0a167f769d98caa3b6ce4e3cc

prepublish script

view details

Jeremy Albright

commit sha 01dcc0d2c0234f28f7aa4178c3b9dda023afba15

release candidate 2

view details

push time in 17 days

push eventJs-Brecht/gatsby-plugin-ts-config

Jeremy Albright

commit sha 98775f77dd43f063240d0aca3e7d01ce3a4ace87

prepublish script prepublish script

view details

Jeremy Albright

commit sha f764a301afdbe7fdba81570140ae8f16a24473f8

release candidate 2

view details

push time in 17 days

push eventJs-Brecht/gatsby-plugin-ts-config

Jeremy Albright

commit sha 916b496f45b730b4a8e01e5022db386239bcdfe4

release candidate 2

view details

push time in 17 days

push eventJs-Brecht/gatsby-plugin-ts-config

Jeremy Albright

commit sha effc3ff5fc886bcd9b7b5865002bb29284739259

prepublish script

view details

push time in 17 days

push eventJs-Brecht/gatsby-plugin-ts-config

Jeremy Albright

commit sha 91119d1b7bad1e1ac87fbe68d6599bea2b9ad8fb

prepublish script

view details

push time in 17 days

create barnchJs-Brecht/gatsby-plugin-ts-config

branch : plugin-resolver

created branch time in 17 days

push eventJs-Brecht/gatsby-starter-pnpm-ts

Jeremy Albright

commit sha 8276d3554154b2c584b6af2ad728d61aba4624c1

remove ts-config resolution

view details

push time in 17 days

issue commentdavewasmer/devcert

localhost is not a valid domain name

devcert uses certutil for managing NSS DBs, and that's what comes with libnss3-tools. Firefox uses NSS DBs, and Chrome does on Linux, too. It would be nice to package all of that up, but there are no bindings for libnss. As a result, devcert relies on the host machine having the library installed.

libnss is an open source library developed by Mozilla, so it's available for anybody to write bindings. I've almost done it myself a few times, but I've got so much other work that is higher priority.

stramel

comment created time in 19 days

issue commentdavewasmer/devcert

Broken password explanation link

https://github.com/davewasmer/devcert#security-concerns

deasems

comment created time in 19 days

issue commentdavewasmer/devcert

localhost is not a valid domain name

@JustFly1984 try adding this to your action, before your gatsby develop command:

- name: Update apt sources
  run: sudo apt-get update
- name: Install libnss3-tools
  run: sudo apt-get install -y libnss3-tools
stramel

comment created time in 20 days

issue commentdavewasmer/devcert

localhost is not a valid domain name

@JustFly1984 I think one way you could fix that is to install libnss prior to running gatsby develop. That way you can tailor it to the environment it is running in.

stramel

comment created time in 20 days

issue commentgatsbyjs/gatsby

gatsby/devcert https fails: Error: "localhost" is not a valid domain name

@JustFly1984 that is a devcert issue, but one unrelated to this one. If libnss is not installed, then it will attempt to install it for you. It is either trying to install the wrong library for Ubuntu 18, or the CI doesn’t have the correct apt sources.

devcert doesn’t really support CI/CD... it’s going to require too much intervention. I guess one way would be to disable the automatic setup of libnss... it’s only going to be needed for browsers anyway, and you probably won’t be running a browser in CI. That should be done from Gatsby; it could use either a new CLI parameter, or watch for process.env.CI to change that configuration parameter when calling devcert. That particular parameter is here: https://github.com/gatsbyjs/gatsby/blob/b95550405c9fb718e70d636512d07d968d49d295/packages/gatsby/src/utils/get-ssl-cert.js#L77

However, all that aside, I still don’t think I’d recommend running devcert in CI/CD. I’m not even sure why you’d run gatsby develop at all in CI/CD.

—-

You will see the warning about the security vulnerability; no way around that. It’s a feature of the package manager. Version 1.1.1 fixed a potential remote execution exploit, so a warning was placed on 1.1.0... but that’s not really something you would need to worry about when running gatsby develop. It’s something you’d need to worry about if you’re running devcert in production.

ngmgit

comment created time in 20 days

issue commentgatsbyjs/gatsby

gatsby/devcert https fails: Error: "localhost" is not a valid domain name

For anyone coming to this later, you can also pin devcert to v1.1.0. The issue was introduced in v1.1.1

ngmgit

comment created time in 21 days

Pull request review commentdavewasmer/devcert

Fix valid domain regex

 type IReturnData<O extends Options = {}> = (IDomainData) & (IReturnCa<O>) & (IRe  * as { caPath: string }  */ export async function certificateFor<O extends Options>(domain: string, options: O = {} as O): Promise<IReturnData<O>> {+  if (VALID_IP.test(domain)) {+    throw new Error('IP addresses are not supported currently');

I think a } was missed here

  if (VALID_IP.test(domain)) {
    throw new Error('IP addresses are not supported currently');
  }
stramel

comment created time in 21 days

push eventJs-Brecht/devcert

James Zetlen

commit sha 6653cbe07dd0b2d022b31a5e924cecde913cca08

fix: Remove protection on CA file after upgrade (#48) * fix: Remove protection on CA file after upgrade * revamped uninstall process * chore: win32 delete warning

view details

James Zetlen

commit sha 0ff7f183be7667496d4214f7dd3a9eabd44c0e87

chore: update changelog and readme

view details

James Zetlen

commit sha 2b1b8d40eda251616bf74fd69f00ae8222ca1171

v1.1.0

view details

James Zetlen

commit sha e0e8ae31c7a5f2371f091f27ced65ed43e7752c2

Fix remote execution vulnerability by switching from execSync to execFileSync (#55) * use execFileSync * add regex validation * fixup logging and interpolation

view details

James Zetlen

commit sha 73b0e6af1bb7d1bbedba3464347c37c2c1857864

chore: update changelog

view details

James Zetlen

commit sha e1389685b9f903b19208cabbe8c80ada33b29cd4

v1.1.1

view details

push time in 21 days

push eventJs-Brecht/gatsby

John Otander

commit sha bd0b5585d6665aa83f1d8af2c80ef5d879c99721

fix(gatsby-recipes): Clean up dist folder before build (#24663)

view details

Kyle Mathews

commit sha 94f490cf1c54d1cb1e4e3dfda1e484541982c483

chore(release): Publish - gatsby-admin@0.1.55 - gatsby-cli@2.12.39 - gatsby-recipes@0.1.33 - gatsby-theme-blog-core@1.5.30 - gatsby-theme-blog@1.6.30 - gatsby-theme-notes@1.3.56 - gatsby-theme-ui-preset@0.0.45 - gatsby@2.22.14

view details

Kyle Mathews

commit sha fb899463777a0c61271338bb2faab231f2a07450

fix(gatsby-recipes): Don't use 4000 as default recipes port as commonly used by people in apps (#24665) fixes https://github.com/gatsbyjs/gatsby/issues/24656

view details

Kyle Mathews

commit sha 200b3c1179069eaad657d09d55f969203cb1845e

chore(release): Publish - gatsby-admin@0.1.56 - gatsby-cli@2.12.40 - gatsby-recipes@0.1.34 - gatsby-theme-blog-core@1.5.31 - gatsby-theme-blog@1.6.31 - gatsby-theme-notes@1.3.57 - gatsby-theme-ui-preset@0.0.46 - gatsby@2.22.15

view details

Lennart

commit sha ff4810c3eb7017f9f3d076d11168a4e5e813eb86

fix(www): Starter star sorting (#24668)

view details

Nicholas Duffy

commit sha e7d21aa65f5d2ae25b06baeec646abc0df5fbea8

Fix Sanity data update script (#24643) * Fix Sanity data update script * Run yarn format

view details

Nicholas Duffy

commit sha ce267dafd7d47a47537e4572b611438551fe8b41

Update benchmark reporting plugin verisons (#24672)

view details

Vincent Ip

commit sha 8dd9437bfa72105dd7fdc27bfaf96036bdb28a31

docs(gatsby-source-filesystem): use comma delimiter for object values (#24638) Co-authored-by: gatsbybot <mathews.kyle+gatsbybot@gmail.com>

view details

Adriano Raiano

commit sha 03e34f3cab2f143c9a406b097597e7b6b943fb41

i18next: Suspense API and React Hooks are not experimental anymore (#24409) * i18next: Suspense API and React Hooks are not experimental anymore * Update docs/docs/localization-i18n.md Co-authored-by: Obinna Ekwuno <obinnacodes@gmail.com>

view details

Henrik Wirth

commit sha 8e4f3408b0437c8112b047e7131d4ae6476e0544

chore(showcase): Add mobileui.dev (#24648)

view details

Matt Kane

commit sha 0e98ad417f56eb5f577d89bd386fad8987e60ee6

chore(gatsby): Export and improve types (#24683)

view details

Timothy Gu

commit sha 19dc8a9649d58194a7ba5a76d5abba6dd0545e78

fix(gatsby-recipes): move strip-ansi to dependencies (#24687) strip-ansi is used by src/providers/utils/get-diff.js, which makes it a dependency. Refs: #20949

view details

Madalyn

commit sha 77d3f06b8886a64594e4bc163461445cac872a33

Reach skip nav example (#21376) * add skip link example to simple starter * update README * add comments to gatsby-browser * add gatsby-image to package.json * update announcer live region to be polite * update readme * add cypress tests * Apply language suggestions from code review Co-Authored-By: Marcy Sutton <marcy@gatsbyjs.com> * remove unneccessary image content from example * remove unnecessary test * run prettier on README.md Co-authored-by: Marcy Sutton <marcy@gatsbyjs.com>

view details

Anish Aggarwal

commit sha 9932f4c4a2e93055493adc0aaf3477aaf7deacf4

fixed link in overview-of-the-gatsby-build-process.md (#24544)

view details

Muescha

commit sha aba2b79c442c6398d406791fa530be601dd3ec32

remove local domain, fix branding (#24662)

view details

Muescha

commit sha 9f10afe7ac0e91a043b3885c8e51f6a126c88a98

fix(blog): impossible foods - remove local links (#24627) * remove local links * fix link, remove local links, code block for example url * Revert "fix link, remove local links, code block for example url" This reverts commit cced561c

view details

Hashim Warren

commit sha e05ca9c1a96ab48e5d53837593906e8f5dc2b910

Fix strapi link (#24697)

view details

Muescha

commit sha 3c55efe1a5d24b1a7b601d997cb40ad54b883cc0

fix(recipe): Preact - brand name (#24699)

view details

Abhishek Jakhar

commit sha 2dbd1c301da106a0089f8524e053d2389bf667e5

fix(www): cleanup of css in guidelines containers + color and logo page (#24651) * cleaned up the guidelines containers * cleaned up the logo page * cleaned up the color page theme-ui * updated style of color component * fix: use functional value * chore: also use responsive array for horizontal padding * chore: functional values * chore: no need to grab from `theme` here * chore: add const `padding` * fix: back to good old media queries We could've done `[6, null, null, 10]` instead, replicating the mobile-first `px` of `Container` that we'd overwrite by using the current approach. Co-authored-by: Florian Kissling <florian.kissling@gmail.com> Co-authored-by: gatsbybot <mathews.kyle+gatsbybot@gmail.com>

view details

Dan Dascalescu

commit sha 678dad624a288988827677a1d252bbcdedd340df

docs: the location prop is only passed to page components (#24664)

view details

push time in 21 days

pull request commentdavewasmer/devcert

Fix valid domain regex

I guess I did 😆. I think it will need to be done eventually, so maybe it will be good to have something on standby. Currently, though, the certificates generated do not use IP SANs. Didn't really think about that when I said it.

Could probably switch the regex to /(?:[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?\.?)+[a-z0-9][a-z0-9-]{0,61}[a-z0-9]/i and would probably work. Also, not sure if 0-9 should be in that first group?

Since, technically, domain names can have numbers in them, it makes sense to keep the 0-9.

That regexp works, but it also matches on just the first octet of an IP address like 127.0.0.1, since the final test, [a-z0-9][a-z0-9-]{0,61}[a-z0-9], requires a minimum of two characters in the last position. So IP addresses will pass the domain name check, but they won't actually be validated.

Maybe there should be a separate regex to match IP addresses, so that they can be matched prior to domain name validation? Then a friendly error could be generated to indicate that IP addresses aren't supported at the moment? Later, when they are supported, the condition could be changed to accept the IP, and a monolithic regular expression wouldn't have to be picked apart to ensure compatibility.

stramel

comment created time in 21 days

pull request commentdavewasmer/devcert

Fix valid domain regex

It doesn't seem to match any IP addresses. Of course, the generated certificates also don't support IP addresses, so maybe it's a good thing for it to fail early when an IP address is provided as hostname

/cc @zetlen

stramel

comment created time in 21 days

issue commentgatsbyjs/gatsby

gatsby/devcert https fails: Error: "localhost" is not a valid domain name

See https://github.com/davewasmer/devcert/issues/56 and https://github.com/davewasmer/devcert/pull/57

ngmgit

comment created time in 21 days

delete branch Js-Brecht/gatsby-source-buttercms

delete branch : fix-collections

delete time in 23 days

issue closedJs-Brecht/gatsby-plugin-ts-config

Add possibility to donate

I spent the whole day to typescriptify a Gatsby project of mine. Your plugin came in handy. I think there should be a donate button somewhere.

💪

closed time in 23 days

openscript

issue commentJs-Brecht/gatsby-plugin-ts-config

Add possibility to donate

Hey @openscript, I'm really glad you found my plugin useful. TBH, I'd never really thought receiving any kind of donations, but as requested, I've added one to the readme (top & bottom).

Please let me know if you think of any features you think it could use, or if you run into any issues. I've got plans right now to add a new utility that will allow for strongly typed plugin options in gatsby-config (discriminated unions don't work properly at the moment), as well as resolving/transpiling local plugins.

openscript

comment created time in 23 days

push eventJs-Brecht/gatsby-plugin-ts-config

Jeremy Albright

commit sha 6e5096a6ba8673d44400bb86c861be607e4da093

donate button in head

view details

push time in 23 days

push eventJs-Brecht/gatsby-plugin-ts-config

Jeremy Albright

commit sha eada7eb00e355b15035c208ef7c637d8d816de6c

donate button

view details

push time in 23 days

issue commentdavewasmer/devcert

localhost is not a valid domain name

The RegExp is here: https://github.com/davewasmer/devcert/blob/d979a93e61a26f8e67ca7b6a86798aca82214aa6/src/constants.ts#L9

I've been really swamped lately, so I don't know when I'll have time to work on that regular expression. It should support IP addresses & single DC (e.g. localhost), but it should also still restrict the domain to valid inputs.

stramel

comment created time in a month

issue commentJs-Brecht/gatsby-plugin-ts-config

Handling custom plugins.

While I was browsing the gatsby documentation, I came across to https://www.gatsbyjs.org/docs/creating-a-local-plugin/#using-requireresolve-and-a-filepath - you probably would have to consider that too.

Yes, this feature would probably be using require.resolve behind the scenes, at least to find the directory for the plugin. It's a pretty easy method for resolving the absolute path to packages, without having to do additional FS checks/realpath resolutions; it will basically packages all of that up into one function call.

However, this plugin already has its own method for resolving gatsby-* endpoints, once the parent directory is found. There's not a pre-packaged method provided for handling that the way it needs to be done.

The purpose for this API will be twofold:

  1. Return a plugin array in a format that Gatsby can understand, with the paths already resolved
  2. Grab the list of gatsby-* endpoints from those plugins and transpile them, so that Gatsby can read them later.

This actually works out really well, because I was already planning on writing a function for resolving Typescript plugins which will allow the use of a proper discriminated union, so that the options you include for the plugins will be strongly typed. The way this project was originally written doesn't work how I wanted it to with discriminated unions; because it needs to allow untyped options, too, there winds up being nothing to discriminate, so it doesn't work how it needs to 😆.

This will give me an opportunity to produce something that will allow for type checking & intellisense on any plugin's options properties.

I'm going to try to get it done this weekend. I've just been really busy lately. Hard to find time to work on these personal projects.

rroslaniec

comment created time in a month

issue commentJs-Brecht/gatsby-plugin-ts-config

Handling custom plugins.

So I'm thinking that the API may look like this:

// gatsby-config.ts

import { resolvePlugin } from 'gatsby-plugin-ts-config';

export default ({ projectRoot }) => {
  plugins: [
    resolvePlugin('foo-plugin'),
    {
      resolve: resolvePlugin('bar-plugin'),
      options: {
        someOptions: 'thisValue',
      }
    }
  ]
}

This could resolve plugins from

  • local plugins directory
  • node_modules

Probably in that order. Not only will it resolve the path for Gatsby, but it will collect the paths of the various gatsby-* files and store them on OptionsHandler.

After the default site's gatsby-config.ts file has finished compiling, it will have collected the paths of all of the additional requested plugins, too. It can then run through that list, compiling as it goes.

One downside to it being done this way is that those files will not be available to the gatsby-config function, which means they cannot be passed to other plugins. For example, when gatsby-plugin-typegen supports passing additional files to it in order to generate types from queries in them, it won't be able to watch those additional plugin files, because the gatsby-config function won't know about them until after it's done resolving.

I think one way to overcome this downside is to execute the resolvePlugin() function before the exported function, instead of inside of it:

// gatsby-config.ts

import { resolvePlugin } from 'gatsby-plugin-ts-config';

const fooPlugin = resolvePlugin('foo-plugin');
const barPlugin = resolvePlugin('bar-plugin');

export default ({ projectRoot, endpoints }) => {
  plugins: [
    fooPlugin,
    {
      resolve: barPlugin,
      options: {
        someOptions: 'thisValue',
      }
    },
    {
      resolve: 'gatsby-plugin-typegen',
      options: {
        watchFiles: endpoints.node,
      }
    }
  ]
}

I suppose an alternative syntax to resolvePlugin() is to make it mimic the structure of the plugins[] array.

const resolvedPlugins = resolvePlugins([
  'foo-plugin',
  {
    resolve: 'bar-plugin',
    options: {
      someOption: 'thisValue',
    }
  }
]);

export default ({ projectRoot, endpoints }) => {
  plugins: [
    ...resolvedPlugins,
    {
      resolve: 'gatsby-plugin-typegen',
      options: {
        watchFiles: endpoints.node,
      }
    }
  ]
}

@rroslaniec let me know if you have any thoughts/suggestions.

rroslaniec

comment created time in a month

created tagJs-Brecht/gatsby-plugin-ts-config

tagv0.2.3

Configure Gatsby to use typescript configuration files

created time in a month

release Js-Brecht/gatsby-plugin-ts-config

v0.2.3

released time in a month

delete tag Js-Brecht/gatsby-plugin-ts-config

delete tag : 0.2.3

delete time in a month

issue closedJs-Brecht/gatsby-plugin-ts-config

'loose' mode configuration must be the same for both @babel/plugin-proposal-class-properties and @babel/plugin-proposal-private-methods

Using this plugin with Babel as transpiler results in the following error:

  Error: [gatsby-plugin-ts-config] An error occurred while reading your gatsby-config!
  /.gatsby/gatsby-config.ts: 'loose' mode configuration must be the same for both @babel/plugin-proposal-class-properties and @babel/plugin-proposal-private-methods

I'm not using a custom Babel config, so I'm assuming this is an issue with this plugin. Setting babel to false and tsNode to true resolves it, but I'd like to use Babel if possible.

closed time in a month

Mrtenz

created tagJs-Brecht/gatsby-plugin-ts-config

tag0.2.3

Configure Gatsby to use typescript configuration files

created time in a month

release Js-Brecht/gatsby-plugin-ts-config

0.2.3

released time in a month

push eventJs-Brecht/gatsby-plugin-ts-config

Jeremy Albright

commit sha 98e3975ad66b9f1ea3a6170aede076253da965cf

babel-preset-gatsby-package version bump * Publish version 0.2.3

view details

push time in a month

Pull request review commentdavewasmer/devcert

Fix remote execution vulnerability by switching from execSync to execFileSync

 type IReturnData<O extends Options = {}> = (IDomainData) & (IReturnCa<O>) & (IRe  * as { caPath: string }  */ export async function certificateFor<O extends Options>(domain: string, options: O = {} as O): Promise<IReturnData<O>> {+  if (!VALID_DOMAIN.test(domain)) {+    throw new Error(`"${domain}" is not a valid domain name.`);+  }

@zetlen FYI, this looks like it is causing #56. I can open a PR to fix it when I have time, but that might not be for a few days

zetlen

comment created time in a month

issue commentdavewasmer/devcert

localhost is not a valid domain name

Oh, I see now you’re using npm. I overlooked that before

stramel

comment created time in a month

issue commentdavewasmer/devcert

localhost is not a valid domain name

What package manager are you using? You should be able to use it to query your dependency tree. Something like yarn why devcert, npm ls devcert, or pnpm ls --filter devcert.

I’m just trying to figure out what version you’re on because an update was published today that would probably cause the problem you’re experiencing

stramel

comment created time in a month

issue commentdavewasmer/devcert

localhost is not a valid domain name

v1.1.1?

stramel

comment created time in a month

delete branch Js-Brecht/gatsby

delete branch : fix-preset-gatsby-package

delete time in a month

issue commentJs-Brecht/gatsby-plugin-ts-config

'loose' mode configuration must be the same for both @babel/plugin-proposal-class-properties and @babel/plugin-proposal-private-methods

This works for me:

  "resolutions": {
    "@babel/preset-env": "7.10.1",
    "@babel/helper-create-class-features-plugin": "7.9.6",
    "@babel/plugin-proposal-class-properties": "7.10.1"
  }
Mrtenz

comment created time in a month

push eventJs-Brecht/gatsby

Jeremy Albright

commit sha 10e13a966c30b54349b9e68bbf494fb3ca800159

remove class-properties from dependencies

view details

push time in a month

pull request commentgatsbyjs/gatsby

fix(babel-preset-gatsby-package): remove explicit `@babel/plugin-proposal-class-properties` and let `@babel/preset-env` add it

I monkey patched gatsby-package to exclude class-properties, and it works.

Versions being used:

  • babel-preset-gatsby-package@0.4.3
  • @babel/preset-env@7.10.2

Question: should @babel/plugin-proposal-class-properties be removed from the dependencies for babel-preset-gatsby-package?

Js-Brecht

comment created time in a month

pull request commentgatsbyjs/gatsby

fix(babel-preset-gatsby-package) adjust loose mode configuration to comply with babel constraint

That results in this error:

Support for the experimental syntax 'classProperties' isn't currently enabled
Js-Brecht

comment created time in a month

push eventJs-Brecht/gatsby

Jeremy Albright

commit sha 2a15fea79f27fc54302b758f1115d734da9fc587

update jest snapshots

view details

push time in a month

pull request commentgatsbyjs/gatsby

fix(babel-preset-gatsby-package) adjust loose mode configuration to comply with babel constraint

Okay, I went ahead and removed @babel/plugin-proposal-class-properties from the plugin list

Js-Brecht

comment created time in a month

push eventJs-Brecht/gatsby

Jeremy Albright

commit sha edf07b335e0e2cca76fd812d8c4c3fd15bd16fa8

remove @babel/plugin-proposal-class-properties

view details

push time in a month

pull request commentgatsbyjs/gatsby

fix(babel-preset-gatsby-package) adjust loose mode configuration to comply with babel constraint

We recently bumped @babel/* packages and we do get those now too in here - but it seems like those are warnings and not errors (as in it's not terminal)

I'm not sure exactly why it's throwing an error on mine; it's the same message, though. The major difference is that mine is doing runtime transpiling through @babel/register, and building Gatsby packages is done on the CLI... ? I don't really know if that's why it throws instead, but it seems reasonable to assume.


so I think we can go ahead with your suggestion to remove explicit class-properties from plugin list (and likely direct dependencies of that preset?) and let preset-env handle this (which should also ensure loose setting is consistent there)

I just want to verify: you want to remove class-properties from preset-gatsby-package? I ask because it sounded like @wardpeet wanted the config to be more explicit, I assume by adding private-methods as well? Unless there's another way to tell preset-env not to include class-properties or private-methods.

Js-Brecht

comment created time in a month

issue commentJs-Brecht/gatsby-plugin-ts-config

Handling custom plugins.

Ohh, yeah... this plugin turns off the transpiler after transpiling your default site’s files. I do that so that it doesn’t interfere with the rest of Gatsby’s processes. I try to keep the transpiler as compatible with Gatsby as I can, but there a couple places I’ve had to deviate.

One thing I could do... by including a utility like I mentioned for resolving local plugins, I can also keep a record of them, and hit them with the transpiler, too, before turning it off

rroslaniec

comment created time in a month

pull request commentgatsbyjs/gatsby

fix(babel-preset-gatsby-package) adjust loose mode configuration to comply with babel constraint

But if I don't do any upgrade, then it works fine.

I totally understand if you don't want to take a chance with this right now. I can also adjust the options of class-properties during runtime; I'm already doing it once for tranform-runtime to inject the absoluteRuntimePath

Js-Brecht

comment created time in a month

pull request commentgatsbyjs/gatsby

fix(babel-preset-gatsby-package) adjust loose mode configuration to comply with babel constraint

I think the install that's being done when my plugin is installed might be winding up with a newer version of @babel/preset-env. If I run yarn upgrade in the Gatsby repository, then try to run a build, I get this error:

Though the "loose" option was set to "true" in your @babel/preset-env config, it will not be used for @babel/plugin-proposal-private-methods since the "loose" mode option was set to "false" for @babel/plugin-proposal-class-properties.
The "loose" option must be the same for @babel/plugin-proposal-class-properties, @babel/plugin-proposal-private-methods and @babel/plugin-proposal-private-property-in-object (when they are enabled): you can silence this warning by explicitly adding
	["@babel/plugin-proposal-private-methods", { "loose": false }]
to the "plugins" section of your Babel config.
Js-Brecht

comment created time in a month

pull request commentgatsbyjs/gatsby

fix(babel-preset-gatsby-package) adjust loose mode configuration to comply with babel constraint

So, with class-properties:

  • loose: true: class members will be defined using an assignment expression.
    var Foo = function Foo() {
       this.y = 'bar';
    }
    
  • loose: false, class members are defined using Object.defineProperty().
    var Foo = function Foo() {
       Object.defineProperty(this, "y", {
          configurable: true,
          enumerable: true,
          writable: true,
          value: 'bar'
       })
    }
    

Seems like the assignment is a little more thorough using Object.defineProperty().

In private-methods:

  • loose: true: private class methods will be defined using Object.defineProperty()
  • loose: false: private class methods will be defined using a WeakSet().

Here it means the difference between the class accessing private methods with the normal property access methods, or by using .get(). Their example uses some helpers that I haven't looked at, so I don't really know exactly what it's doing without looking deeper. I think the point of the loose property is whether or not private members can be accessed from outside the class.

Js-Brecht

comment created time in a month

issue commentJs-Brecht/gatsby-plugin-ts-config

Handling custom plugins.

Yeah, that's one drawback I hadn't thought of yet. Thanks for bringing it up.

This plugin takes advantage of the "theme" system that Gatsby uses, which allows plugins to have a gatsby-config. This lets it set up the transpiler for gatsby-config and gatsby-node, which is what it needs so that you can write them in typescript. The problem with that is your config basically gets relegated to the next level.

So instead of doing this to get all of your default site plugins: default-site -> gatsby-config

It is now doing this: default-site -> gatsby-plugin-ts-config -> gatsby-config

And Gatsby doesn't look in the plugins folder local to any of the plugins, because that just opens up a can of worms.

There's a couple of things that can be done. If you make the path to the local plugin an absolute path, then it should work without a problem:

// If gatsby-config.ts is in a subdirectory
const localPlugins = path.join.bind(path, path.resolve(__dirname, '..', 'plugins'));
const resolveLocalPlugin = (project) => path.dirname(
  require.resolve(
    localPlugins(project, 'package.json')
  )
)
module.exports = {
  plugins: [
    resolveLocalPlugin('gatsby-plugin-fonts')
  ]
}

OR, I could include a utility that will do this for you... which I think I will do anyway. This plugin is due for some more work, to make static typing for gatsby-config better.

rroslaniec

comment created time in a month

pull request commentgatsbyjs/gatsby

fix(babel-preset-gatsby-package) adjust loose mode configuration to comply with babel constraint

We have shippedProposals: true in our preset-env settings which make it so preset doesn't add few of plugins (including class properties ones)

Looks like they use a round-about way to define what plugins the preset pulls:

So it appears as though class-properties and private-methods are being used, but here it sets class-properties to be the same as private-methods. Not sure of the implications there.

tho I need to look up meaning of loose setting

Yeah, I'm not really sure about that either. If it cannot be loose: true, then private-methods could also be imported, and they could both be set to loose: false, that way it overrides what preset-env is pulling 🤷‍♂️

Js-Brecht

comment created time in a month

issue closedJoviDeCroock/prefresh

Hooks break components when using ts-loader + babel-loader + @prefresh/webpack

There seems to be some issue using hooks in components when using ts-loader in combination with babel-loader + @babel/preset-env and @prefresh/webpack. For some reason, components with hooks become undefined.

I have created a reproduction here. If you run the start npm script, you will see the issue I'm talking about in your browser.

If you comment out these lines (remove @babel/preset-env), the problem goes away.

If you return those lines and comment out these lines (remove ts-loader), then everything works. But they can't seem to coexist.

Perhaps I have it misconfigured in some way. Is there something in @babel/preset-env that would cause this? I would very much prefer to use ts-loader together with babel-loader, because there are also transformations that I want Typescript to make. However, in development I am using @prefresh/webpack, so it refuses to work correctly.

One thing that is different between my main project repo and this reproduction: in my project repo, the element becomes <undefined>, and doesn't throw the error in the browser. There is a lot more going on there, though, so there's apparently something that is allowing it to pass through as undefined. I just didn't bother taking the time to build it up to that point. I just wanted to showcase the failure.

closed time in a month

Js-Brecht

issue commentJoviDeCroock/prefresh

Hooks break components when using ts-loader + babel-loader + @prefresh/webpack

Oh! Good catch! I forgot I had set that to CJS while I was testing a TS transformer I was working on.

I also hadn't noticed the preact/debug import... this was a quick project I scaffolded with preact create typescript; I ripped a lot of it out, but I guess I missed that bit. Once I remove that require(), you can see the actual problem I was encountering: inside of <App>, I have a text box that uses useState for state management. It will wind up being mounted to the DOM as <undefined>.

But you're absolutely right. Changing the module setting in tsconfig fixes the entire issue. Thanks!

Js-Brecht

comment created time in a month

issue openedJoviDeCroock/prefresh

Hooks break components when using ts-loader + babel-loader + @prefresh/webpack

There seems to be some issue using hooks in components when using ts-loader in combination with babel-loader + @babel/preset-env and @prefresh/webpack. For some reason, components with hooks become undefined.

I have created a reproduction here. If you run the start npm script, you will see the issue I'm talking about in your browser.

If you comment out these lines (remove @babel/preset-env), the problem goes away.

If you return those lines and comment out these lines (remove ts-loader), then everything works. But they can't seem to coexist.

Perhaps I have it misconfigured in some way. Is there something in @babel/preset-env that would cause this? I would very much prefer to use ts-loader together with babel-loader, because there are also transformations that I want Typescript to make. However, in development I am using @prefresh/webpack, so it refuses to work correctly.

One thing that is different between my main project repo and this reproduction: in my project repo, the element becomes <undefined>, and doesn't throw the error in the browser. There is a lot more going on there, though, so there's apparently something that is allowing it to pass through as undefined. I just didn't bother taking the time to build it up to that point. I just wanted to showcase the failure.

created time in a month

create barnchJs-Brecht/preact-prefresh-hooks-issue

branch : master

created branch time in a month

created repositoryJs-Brecht/preact-prefresh-hooks-issue

created time in a month

push eventJs-Brecht/gatsby

Jeremy Albright

commit sha 7b9a7212e145dc34ccdda23a21cb14c260187a18

update snapshots for tests

view details

push time in a month

PR opened gatsbyjs/gatsby

fix error from babel about `loose: true`

Description

A constraint was added to @babel/preset-env recently, which is causing babel-preset-gatsby-package to throw the error shown here: https://github.com/Js-Brecht/gatsby-plugin-ts-config/issues/11. (I use babel-preset-gatsby-package for transpiling TS gatsby-* files from gatsby-plugin-ts-config).

Apparently, if loose: true is set for @babel/plugin-proposal-private-methods, then it must also be set to true for @babel/plugin-proposal-class-properties. According to this comment, both @babel/plugin-proposal-private-methods and @babel/plugin-proposal-class-properties are included by @babel/preset-env when shippedProposals: true, and they're assigned uniform options then. However, babel-preset-gatsby-package imports @babel/plugin-proposal-class-properties itself, which overrides that option.

To fix it, I've just added loose: true to @babel/plugin-proposal-class-properties so that it matches @babel/preset-env. Since @babel/preset-env imports those plugins itself, maybe @babel/plugin-proposal-class-properties could just be removed from the list?

+8 -3

0 comment

1 changed file

pr created time in a month

more