js-brecht / gatsby-plugin-ts-config Goto Github PK

This plugin's initial design has resulted in some compatibility issues that simply require too many workarounds. This is primarily due to the "proxy" method that was used to source the desired gatsby-* files.

This issue is to track the plan for v2, but will be implemented incrementally. OP will be updated with progress as it becomes available

Issues

• If gatsby-config.ts is in the root directory of the default site, it will cause it to be run twice; once by this plugin, and once by Gatsby. This results in node ownership issues, and of course the multiple execution. See #2
• The proxy method employed also results in additional node ownership issues because gatsby-node isn't being run as the default site. See #18
• A singleton pattern is used in various places to support the proxy method. This, as well as the proxy method itself, breaks Gatsby theme compatibility. See #20.
• To remain compatible with yarn2/pnpm, the plugins from gatsby-config have to be resolved to absolute paths. This breaks Gatsby's deduplication, as well as their internal plugin overrides. See #26, #27
• Various (potential) issues with Gatsby v3 due to the obfuscation of imports, and other possible problems. See #29
• The highly dynamic nature of the sourcing breaks static analysis, which means non-critical compatibility issues with the Gatsby dev process. Gatsby dev doesn't do static analysis/import tracing yet (I am looking into implementing in core), but the current plugin design would not work with it.

Solution

To fix these requires changing the majority of the design, so it is simpler to do a complete rewrite. The proxy method will be replaced by isolated endpoints:

pseudo-code: pattern subject to change

// /gatsby-config.js
const { useGatsbyConfig } = require("gatsby-plugin-ts-config");

module.exports = useGatsbyConfig("./.gatsby/config", {
  ... custom transpiler options ...
  ... usual plugin options ...
});

// For the purposes of static analysis
module.exports = useGatsbyConfig(() => require("./.gatsby/config"), {
  ... custom transpiler options ...
  ... usual plugin options ...
});

pseudo-code: pattern subject to change

// /gatsby-node.js
const { useGatsbyNode } = require("gatsby-plugin-ts-config");

module.exports = useGatsbyNode("./.gatsby/node", {
  ... custom transpiler options ...
  ... usual plugin options ...
});

// For the purposes of static analysis
module.exports = useGatsbyNode(() => require("./.gatsby/node"), {
  ... custom transpiler options ...
  ... usual plugin options ...
});

These "isolated endpoints" will be able to share options between them for each project/theme that uses the plugin. Only one will need to be configured, so you could have /gatsby-config.js, /.gatsby/config.ts, and /gatsby-node.ts; or you could simply use gatsby-node.js, and point it to a Typesecript version... no gatsby-config required.

Because gatsby-browser and gatsby-ssr already support Typescript (they are run through Webpack by Gatsby), and proxying them to a different location breaks themes (and possibly incremental builds), they will need to be set up manually by the end user.

Features

Some new features will be available in v2:

Builder Pattern

The idea here is to have a working POC for a new plugin design pattern that can be used with Gatsby. This would be opt-in

It would look something like this:

// plugin-types.ts
export type MyPluginOptions = {
  foo: string
}

// gatsby-node.ts
import type { GatsbyNodeBuilder } from "gatsby-plugin-ts-config";
import type { MyPluginOptions } from "./plugin-types";

type MyPluginBuilder = GatsbyNodeBuilder<MyPluginOptions>;

// sourceOptions are options passed around between endpoints by gatsby-plugin-ts-config
// includes import chain and property bag
const pluginBuilder: MyPluginBuilder = (builder, sourceOptions) => {
  builder.sourceNodes<MyNodeType>((actions, options) => {
    // I'm strongly typed
    actions.createNode({ ... })

    // I'm strongly typed
    console.log(options.foo);
  });
}

export default pluginBuilder;

// To modularize the logic, accept an array of builder functions
import { sourceNodes } from "./source-nodes";
import { createPages } from "./create-pages";
const builders = [
  sourceNodes,
  createPages,
];

export default builders;

// gatsby-config.ts
import type { GatsbyConfigBuilder, PluginDefs } from "gatsby-plugin-ts-config"; 
import type { SomePluginType } from "some-other-plugin";
import type { MyPluginOptions } from "./plugin-types";

type MyGatsbyConfig = GatsbyConfigBuilder<MyPluginOptions>;

const configBuilder: MyGatsbyConfig = (builder, sourceOptions) => {
  // Allow merging any properties into the config, loosely typed
  builder.merge({
    ...
  });

  // Add siteMetadata.  Optional generic type parameter
  builder.siteMetadata<RequiredSiteMetadata>({
    ...
  });

  // Add loosely typed plugin definitions
  // Also looks at/transpiles local plugins
  builder.addPlugins([
    ...
  ])

  // Add strongly typed plugin definitions
  builder.addPlugins<PluginDefs<SomePluginType | SomeOtherPluginType>>([
    ...
  ]);
}

export default configBuilder;

// Also accept an array (for modularization)

Definitions

• JIT: Just In Time
• Activated: A gatsby-* js file that uses the endpoint transpiler function provided by this plugin
• Active Pattern: An activated module that exports a function to be consumed/processed in order to generate the content for Gatsby's consumption
• Builder Pattern: See Builder Pattern above

Specifications

• Babel or TS Node for JIT transpiling - #32
  • Custom transpiler options merge - #32
• All gatsby-* represent themselves (no proxy) - #32
• Only one of gatsby-config or gatsby-node required to be activated - #32
  • Don't need gatsby-config activated in order to use Typescript gatsby-node
  • Don't need gatsby-node to be activated if gatsby-config is (can use /gatsby-node.ts)
  • Caveat: cannot use only gatsby-node and expect /gatsby-config.ts to be transpiled, since gatsby-node is run later than gatsby-config
• Shared options between gatsby-config & gatsby-node - #32
  • One of:
    • Merge options defined in gatsby-config with the ones defined in gatsby-node when it runs?
    • Replace options defined in gatsby-config with the ones defined in gatsby-node when it runs?
• Options/transpilers isolated per runtime (themes support) - #32
  • Tied to call sites - #32
• Callback import method (for static analysis support) - #32
• Local plugin transpiling - #32
  • Fully processed property bag passed down from parent & cloned
• Active pattern for activated modules - #32
  • Requires activated module
  • Active pattern accepts metadata passed between endpoints by this plugin
    • Import chain - #32
    • Property bag (mutable props defined by end user; isolated by project/theme) - #32
• Builder pattern for activated modules

Priorities

1. Isolated endpoints
   • Should support the same "Active module" pattern that v1 supports (default export function)
2. Plugin builder pattern

Estimated Timeframe (conservative)

• Isolated Endpoints: 05-23-2021 - #32
• Builder Pattern: 06-06-2021

Hi there,

First of all: thanks for this great library! Seems to be really underappreciated. Hope it will get more stars soon 🙂

Problem description:

I have a problem with an ES6 module dependency though. I am not 100% sure if it is related to this library but the name is mentioned in the error output, so it might be the case.

The dependency I use is capacitor-fcm.

Possible solution?

I found a Gatsby plugin (gatsby-plugin-compile-es6-packages) that should solve this problem, but it seems not to be working together with gatsby-plugin-ts-config.

Error log:

 ERROR 

[gatsby-plugin-ts-config] An error occurred while reading your gatsby-config!
Unexpected token export



  Error: C:\Users\flogy\Documents\Development\my-app\node_modules\capacitor-fcm\dist\esm\index.js:1
  (function (exports, require, module, __filename, __dirname) { export * from "./plugin";
                                                                ^^^^^^
  SyntaxError: Unexpected token export

  - v8-compile-cache.js:226 NativeCompileCache._moduleCompile
    [my-app]/[v8-compile-cache]/v8-compile-cache.js:226:18

  - v8-compile-cache.js:172 Module._compile
    [my-app]/[v8-compile-cache]/v8-compile-cache.js:172:36

  - index.js:99 Module._compile
    [my-app]/[pirates]/lib/index.js:99:24

  - loader.js:789 Module._extensions..js
    internal/modules/cjs/loader.js:789:10

  - index.js:104 Object.newLoader [as .js]
    [my-app]/[pirates]/lib/index.js:104:7

  - loader.js:653 Module.load
    internal/modules/cjs/loader.js:653:32

  - loader.js:593 tryModuleLoad
    internal/modules/cjs/loader.js:593:12

  - loader.js:585 Function.Module._load
    internal/modules/cjs/loader.js:585:3

  - loader.js:692 Module.require
    internal/modules/cjs/loader.js:692:17

  - v8-compile-cache.js:159 require
    [my-app]/[v8-compile-cache]/v8-compile-cache.js:159:20

  - CapacitorStore.ts:14 Object.<anonymous>
    C:/Users/flogy/Documents/Development/my-app/src/Stores/CapacitorStore.ts:14:21

  - v8-compile-cache.js:178 Module._compile
    [my-app]/[v8-compile-cache]/v8-compile-cache.js:178:30

  - index.js:99 Module._compile
    [my-app]/[pirates]/lib/index.js:99:24

  - loader.js:789 Module._extensions..js
    internal/modules/cjs/loader.js:789:10

  - index.js:104 Object.newLoader [as .ts]
    [my-app]/[pirates]/lib/index.js:104:7


not finished open and validate gatsby-configs - 1.124s

Do you see any way to get this work? Thanks in advance!

I initially installed this plugin in order to load packages of my monorepo as described here. It works just fine with the mentioned plugin to import them in my typescript files.

Then, another use case occured. I also wanted to load a variable from one of the packages in my gatsby-config.js like so: const { global } = require('@shared-ui/design');. The module was not found, so I thought this plugin might help.

I have moved all new ts files to the .gatsby folder and used your example babel configuration. The following error arises:

Error: [gatsby-plugin-ts-config] An error occurred while reading your gatsby-config!
  Cannot find module @shared-ui/design'

Is this setup supposed to work or am I missing something? Note that the gatsby tsconfig extends from my root tsconfig, where the paths are defined. In my gatsby application I do not have a babelconfig yet.

Many thanks!

We're now on Gatsby 4.18.0, but this plugin only supports 2.x.x or 3.x.x, giving the following error on install

npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: simple-gatsby-boilerplate@undefined
npm ERR! Found: [email protected]
npm ERR! node_modules/gatsby
npm ERR!   gatsby@"4.18.0" from the root project

I attempted to fix it by adding the following to my package.json...

{
  "overrides": {
    "gatsby-plugin-ts-config": {
      "gatsby": "^4.18.0"
    }
  }
}

...to force the versions but this causes the following error during gatsby build:

11:19:04 AM:
ERROR We encountered an error while trying to load your site's gatsby-config. Please fix the error and try again.

11:19:04 AM:
11:19:04 AM:
  Error: [gatsby-plugin-ts-config]: Debug Failure. False expression: Non-string   value passed to `ts.resolveTypeReferenceDirective`, likely by a wrapping packa  ge working with an outdated `resolveTypeReferenceDirectives` signature. This i  s probably not a problem in TS itself.

with [email protected]

I have the following folder structure

| - gatsby-config.js
| - gatsby/
   | - gatsby-node.ts
   | - gatsby-config.ts
   | - tsconfig.json
   .........
| - src/
   | - assets/
      | - my-cool-image.jpg
   | - content.ts
   .........

content.ts contains some static content which is imported into gatsby-node.ts and used to generate a couple of pages, but content includes an import from ./assets/my-cool-image.jpg which generates the following error:

Error: [gatsby-plugin-ts-config]: Could not find source file: '/PATH_TO_PROJECT/src/assets/my-cool-image.jpg'.

The assets file is used within src where it is correctly handled by webpack, but here it is treated as if the file doesn't exist (presumably by node as it can't read the file)

Is it possible to pass something into gatsby-plugin-ts-config to tell node to ignore certain files? Or to tell it to resolve it to something else (like just an empty string)? Or is this a bug inside gatsby-plugin-ts-config?

If relevant, the imports are as modern module imports:

import myCoolImage from './assets/my-cool-image.jpg';

rather than the old require, which could be used conditionally tbf if I switched back

Gatsby uses a scoped require when resolving plugins (it resolves them from the context of a theme/plugin that provides them), and gatsby-plugin-ts-config proxies the default site's plugins, Gatsby is generally unable to resolve them. Because of this, they are resolved to absolute paths before passing them back to Gatsby.

The issue with this is that it will break de-duplication. For example, if the default site defines a plugin, say gatsby-plugin-sharp and a theme defines the same plugin, the default site's plugin metadata becomes

{
  resolve: '/absolute/path/to/node_modules/gatsby-plugin-sharp'
}

Meanwhile, the theme's plugin metadata will likely look like:

{
  resolve: 'gatsby-plugin-sharp'
}
// or
[
  'gatsby-plugin-sharp'
]

Gatsby's plugin de-duplication looks at the resolve and options properties on the plugin metadata. If they are the same, they are de-duplicated. Any plugins served via gatsby-plugin-ts-config will not match plugins defined using just its name.

See #24 and gatsbyjs/gatsby#28523

Hey,
I've figure it out that after using that plugin mine custom plugins are not discovered - even I've added also gatsby-config.js files to them.

 ERROR #10226  CONFIG

Couldn't find the "gatsby-plugin-fonts" plugin declared in "/path/to/project/node_modules/gatsby-plugin-ts-config/gatsby-config.js".

Tried looking for an installed package in the following paths:
 - /path/to/project/node_modules/gatsby/dist/bootstrap/load-themes/node_modules/gatsby-plugin-fonts
 - /path/to/project/node_modules/gatsby/dist/bootstrap/node_modules/gatsby-plugin-fonts
 - /path/to/project/node_modules/gatsby/dist/node_modules/gatsby-plugin-fonts
 - /path/to/project/node_modules/gatsby/node_modules/gatsby-plugin-fonts
 - /path/to/project/node_modules/gatsby-plugin-fonts
 - /path/to/node_modules/gatsby-plugin-fonts
 - /Users/rroslaniec/node_modules/gatsby-plugin-fonts
 - /Users/node_modules/gatsby-plugin-fonts
 - /node_modules/gatsby-plugin-fonts

There is no lookup in /path/to/project/plugins folders (https://www.gatsbyjs.org/docs/creating-a-local-plugin/)

gatsby-plugin-fonts is our custom local plugin.

Hi

I just updated to v2.1.0 and found that the pluginOptions has changed and more specifically that the configDir is gone? Is this true or am I missing something? If it's gone is there a particular reason?

I really liked that feature because I could keep all my .ts configs In a separate folder and only have Gatsby-config.js in the root instead of all 4 config files in the root that just points to a .ts version of themselves.

Thanks again for a great plugin
Have a good day

Hey JS thank you for your work to bring Gatsby into the modern world. We've used both the plugin and the upcoming gatsby-ts module successfully in a few projects now, but wanted to report that our builds break when we add typescript code to the files.

So like in gatsby-node.ts, import and export works and if we simply leave out TS code it all compiles. However, as soon as some types are added the compiler chokes.

This is using all the latest Gatsby 4.52 etc.

Here it is failing on an "as" cast,

failed Validating Rendering Engines - 1.342s

 ERROR #98001  WEBPACK

Built Rendering Engines failed validation failed validation.

  Error: Module build failed (from ./node_modules/gatsby/dist/schema/graphql-engine/webpack-remove-apis-loader.js):
  SyntaxError: unknown: Missing semicolon. (86:5)
    84 |     ?.components.filter((c) =>
    85 |       CMSData.is.resourceSection(c),
  > 86 |     ) as CMSData.ResourceSection[];
       |      ^
    87 |
    88 |   const featuredMap = resourceSections.reduce((prev, s) => {
    89 |     const featured = s.resources.find((r) => r.featured);

  - index.js:541 Parser._raise
    [project]/[@babel]/parser/lib/index.js:541:17

And here it is choking very hard on some types around the main export -- the error message has added some weird spaces and I even saw it error with a bunch of nonsense characters like numbers truncating some lines, so it's y'know babel barfing,

  Error: Module build failed (from ./node_modules/gatsby/dist/schema/graphql-engine/webpack-remove-apis-loader.js):
  SyntaxError: unknown: Missing semicolon. (9:4)
     7 | import { CMSData } from './src/config/cms-types';
     8 |
  >  9 | type QueryBlock<T = object> = { edges: { node: { fr  ontmatter: T } }[] };
       |     ^
    10 |
    11 | export const createPages: GatsbyNode['createPages'] = async ({
    12 |   actions,

  - error.js:147 Parser._raise

I tried adding the js config file and setting it to ts-node, with my standard script compiling options, but still got this webpack + babel error.

I see the new 2.0 version changes how this plugin works, however, it would be great to see a basic example of what the 'opts' looks like. Is it optional? Does it have default settings?

It's great to know the fields it can take, but there is no mention of what is required.

Hi

Am tying an upgrade to gatsby v4, however the build is failing.

A change in gatsby 4 (https://github.com/gatsbyjs/gatsby/pull/33413/files) verifies the rendering engine to only allow node.js imports (and those in the .cache folder). However when using this plugin it tries to require the project's /package.json which breaks the build.

The gatsby build error is :

failed Validating Rendering Engines - 1.763s

 ERROR #98001  WEBPACK

Built Rendering Engines failed validation failed validation.

Please open an issue with a reproduction at https://github.com/gatsbyjs/gatsby/issues/new for more help


  Error: Generated engines use disallowed import "/Users/cameronbraid/workspace-new/drivenow-octane/package.json". Only allowed imports are to Node.js builtin modules   or 
engines internals.
  
  - child.ts:60 Function._module.default._load
    [gatsby-virtual-27f6b46480]/[gatsby]/src/utils/validate-engines/child.ts:60:11
  
  - loader:1005 Module.require
    node:internal/modules/cjs/loader:1005:19
  
  - helpers:102 require
    node:internal/modules/cjs/helpers:102:18
  
  - index.js:714801 Object.<anonymous>
    /Users/cameronbraid/workspace-new/drivenow-octane/.cache/query-engine/index.js:714801:19
 

the import that causes the issue in .cache/query-engine/index.js:714801:19 : the exports.pkgJson assignment below

/***/ }),
/* 3934 */
/***/ (function(__unused_webpack_module, exports, __webpack_require__) {

"use strict";

var __importDefault = (this && this.__importDefault) || function (mod) {
    return (mod && mod.__esModule) ? mod : { "default": mod };
};
Object.defineProperty(exports, "__esModule", ({ value: true }));
exports.apiTypeKeys = exports.pluginName = exports.pkgJson = exports.thisRoot = void 0;
var path_1 = __importDefault(__webpack_require__(12));
exports.thisRoot = path_1.default.resolve(__dirname, "..", "..");
exports.pkgJson = require(path_1.default.join(exports.thisRoot, "package.json"));
exports.pluginName = exports.pkgJson.name;
exports.apiTypeKeys = ["config", "node"];
//# sourceMappingURL=constants.js.map

looking for what requires 3934 I found this : (see line with var constants_1 = __webpack_require__(3934);)

/***/ }),
/* 3974 */
/***/ (function(__unused_webpack_module, exports, __webpack_require__) {

"use strict";

var __importDefault = (this && this.__importDefault) || function (mod) {
    return (mod && mod.__esModule) ? mod : { "default": mod };
};
Object.defineProperty(exports, "__esModule", ({ value: true }));
exports.transpilePlugins = exports.resolvePlugin = void 0;
var path_1 = __importDefault(__webpack_require__(12));
var fs_tools_1 = __webpack_require__(3938);
var node_1 = __webpack_require__(3937);
var constants_1 = __webpack_require__(3934);
var project_1 = __webpack_require__(3975);
var resolvePlugin = function (relativeTo, pluginName, localOnly) {
    var scopedRequire = (0, node_1.createRequire)(relativeTo + "/:internal:");
    try {
        var pluginPath = path_1.default.dirname(scopedRequire.resolve(pluginName + "/package.json"));
        return localOnly ? void 0 : {
            path: pluginPath,
            pkgJson: require(pluginPath + "/package.json"),
        };
    }
    catch (err) {
        var pluginDir = path_1.default.resolve(relativeTo, "plugins", pluginName);
        var pkgJsonPath = path_1.default.join(pluginDir, "package.json");
        var pkgJson = (0, fs_tools_1.getFile)(pkgJsonPath);
        if (pkgJson && pkgJson.isFile()) {
            return {
                path: pluginDir,
                pkgJson: require(pkgJsonPath),
            };
        }
        return;
    }
};
exports.resolvePlugin = resolvePlugin;
var transpilePlugins = function (project, type, processApiModule, plugins) {
    if (plugins === void 0) { plugins = []; }
    plugins.forEach(function (plugin) {
        var pluginName = plugin.resolve;
        if (!pluginName)
            return;
        var projectRoot = project.projectRoot;
        var pluginDetails = (0, exports.resolvePlugin)(projectRoot, pluginName, type === "local-only");
        if (!pluginDetails)
            return; // We shouldn't transpile this plugin
        var pluginPath = pluginDetails.path, pkgJson = pluginDetails.pkgJson;
        project.linkPluginImports(pluginName);
        constants_1.apiTypeKeys.forEach(function (type) {
            var gatsbyModuleName = "./gatsby-" + type;
            var apiPath = (0, fs_tools_1.resolveFilePath)(pluginPath, gatsbyModuleName);
            if (!apiPath)
                return; // This `gatsby-*` file doesn't exist for this local plugin
            processApiModule({
                init: apiPath,
                project: project_1.Project.getProject({
                    apiType: type,
                    projectMeta: {
                        projectRoot: pluginPath,
                        projectName: pluginName,
                        pkgJson: pkgJson,
                    },
                    options: project.options,
                    propBag: project.propBag,
                }, true),
                unwrapApi: type === "node",
            });
        });
    });
};
exports.transpilePlugins = transpilePlugins;
//# sourceMappingURL=plugin-transpiler.js.map

Then based on the sourceMappingURL=plugin-transpiler.js.map hint, I looked in project for "plugin-transpiler.js" :

❯ grep -r plugin-transpiler .
Binary file ./.yarn/cache/gatsby-plugin-ts-config-npm-2.1.3-93aa5f6aab-e7003d3722.zip matches
./.cache/query-engine/index.js://# sourceMappingURL=plugin-transpiler.js.map
Binary file ./.cache/webpack/query-engine/index.pack matches
Binary file ./.cache/webpack/query-engine/0.pack matches

Which lead me to be https://github.com/Js-Brecht/gatsby-plugin-ts-config/blob/64e6a4b2db4e5c692e99db6399adbc6b7ad73045/src/lib/plugin-transpiler.ts

So, either this plugin needs to not require package.json or gatsby 4 needs to permit it be imported

I notice that I couln't override gatsby-plugin-page-creator with this plugin

The reason is, Gatsby will compare the resolve prop like here:

https://github.com/akshayymahajan/gatsby/blob/05d65363bcd2a37fc65ca619c62279cbd9ba62b2/packages/gatsby/src/bootstrap/load-plugins/load.js#L224

        plugin.resolve === `gatsby-plugin-page-creator` &&

I noticed that gatsby-config.ts gets the config options provided by this plugin, but does not seem to receive the original config object passed to gatsby-config.js when working in a theme or plugin. Is there some way to access these in my ts config file?

Hi, I'm trying to use this plugin in a Gatsby v3.0 project and running into this error immediately after gatsby develop:

error The site's gatsby-config.js failed validation:

"__esModule" is not allowed
not finished open and validate gatsby-configs - 0.542s

Is this an incompatibility with v3 or perhaps something you might have come across before?

// gatsby-config.js

const { generateConfig } = require("gatsby-plugin-ts-config")
module.exports = generateConfig({ configDir: "gatsby-config" })

All gatsby .ts files in the gatsby-config folder

Does this plugin support tsx files, specifically gatsby-browser.tsx?

I'm getting an error when I run gatsby build (but not gatsby develop). Specifically, static HTML rendering is failing because a provider is not getting wrapped. I put a console.log statement at the top of my gatsby-browser.tsx file, but the message never appears in the terminal (unlike for gatsby-node.ts or gatsby-config.ts). I also put a console.log statement inside a wrapRootElement function, but that also doesn't write.

Hi

Thank you so much for an awesome plugin and for all the time you invest into this! It's appreciated!

When I use this plugin (v. 2.1.0) I get a huge list of unmet peer dependencies from your plugin.
Now, I'm not a wiz when it comes to npm packages and peer dependencies, so I'm not sure if it's me who are missing something in my package.json or if it's in fact your plugin that needs some updating :)

It would be awesome not to have all these warnings on each build

Thanks again
Have a good day

Hey!

Apologies if this is actually completely unrelated to this package but Installing this and making the recommended project structure changes are the only changes since the last successful run.

I'm getting this error after gatsby clean && gatsby build:

[gatsby-plugin-ts-config] An error occurred while reading your gatsby-node!                                                                                                                                 
[BABEL] /Users/phil/repos/phil-barber/.gatsby/gatsby-node.ts: `babel-preset-gatsby` has been loaded, which consumes config generated by the Gatsby CLI. Set `NODE_ENV=test` to bypass, or run `gatsby build`
 first. (While processing: "/Users/phil/repos/phil-barber/node_modules/babel-preset-gatsby/index.js")

My project structure is as mentioned in the README:

.
├── .gatsby
    ├── gatsby-config.ts
    ├── gatsby-node.ts
    ├── gatsby-browser.ts
    ├── gatsby-ssr..ts
    └── wrap-with-provider.tsx
└── gatsby-config.js

Here's my .babelrc

{
  "plugins": [
    "@babel/plugin-proposal-export-default-from",
    "babel-plugin-styled-components"
  ],
  "presets": [
    ["@babel/preset-typescript", { isTSX: true, allExtensions: true }],
    "babel-preset-gatsby"
  ]
}

tsconfig:

{
  "compilerOptions": {
    "outDir": "./dist/",
    "sourceMap": true,
    "noImplicitAny": true,
    "module": "commonjs",
    "target": "es2019",
    "jsx": "react",
    "lib": ["dom", "esnext"],
    "esModuleInterop": true,
    "skipLibCheck": true
  },
  "include": ["./src/**/*", ".gatsby/*"]
}

gatsby-config.js

const { generateConfig } = require('gatsby-plugin-ts-config');

module.exports = generateConfig({
  configDir: '.gatsby',
});

Let me know if there's any other info you need to help debug this. I'm trying to make a minimal reproduction from the gatsby-starter-typescript project for you but running into separate issues there so thought I'd post this first 🤦‍♂️

Hello,

I'm trying to use this plugin, but I'm encountering the following problem:

Error: [gatsby-plugin-ts-config]: [gatsby-plugin-ts-config]: Attempting to link plugin gatsby-source-filesystem to project gatsby-pages failed.
  Plugin gatsby-source-filesystem has already been linked

This is my config:

import { FileSystemConfig } from 'gatsby-source-filesystem';

includePlugins<FileSystemConfig | string>([
  {
    resolve: 'gatsby-source-filesystem',
    options: {
      name: 'product',
      path: `${STORAGE_PATH}/products`,
      ignore: ['**/.git', '.git'],
    },
  },
  {
    resolve: 'gatsby-source-filesystem',
    options: {
      name: 'content',
      path: `${STORAGE_PATH}/contentful`,
      ignore: ['**/.git', '.git'],
    },
  },

What am I doing wrong?

As per the readme, I was under the assumption I could just use the filename without .ts ending:

// gatsby-config.js
const { useGatsbyConfig } = require('gatsby-plugin-ts-config');
module.exports = useGatsbyConfig('./gatsby-config');

However, I get errors relating specifically to the gatsby-theme-i18n plugin:

Those errors are resolved when I specify .ts explicitly:

// gatsby-config.js
const { useGatsbyConfig } = require('gatsby-plugin-ts-config');
module.exports = useGatsbyConfig('./gatsby-config.ts');

No errors:

I have a mono repo setup where other packages exports can be in .ts files.

import * as common from '@newrade/core-common';
import * as core from '@newrade/core-gatsb-config';
import * as conf from '@newrade/core-gatsb-config/config';
import { getAppUrl, loadDotEnv } from '@newrade/core-utils';
import path from 'path';
import packageJson from './package.json';
import { Env, ENV } from './types/dot-env';

const env = loadDotEnv<ENV>({
  schema: Env,
  dotEnvPath: path.resolve(__dirname, '.env'),
  packageName: packageJson.name,
  printEnvVariables: true,
});

/**
 * Configure your Gatsby site with this file.
 *
 * See: https://www.gatsbyjs.org/docs/gatsby-config/
 */
const config: conf.GastbySiteConfig = {
  flags: conf.gatsbySiteFlags,
  siteMetadata: {
    title: `CDPQ`,
    description: `Site de référence pour le design à la CDPQ`,
    siteUrl: getAppUrl(env),
    siteEnv: env.APP_ENV,
    languages: {
      langs: [common.SITE_LANGUAGES.EN_CA, common.SITE_LANGUAGES.FR_CA],
      defaultLangKey: common.SITE_LANGUAGES.FR_CA,
    },
  },
  plugins: [
    /** template */
    core.getGatsbyPluginReactHelmet(),
    /** js/ts/react */
    core.getGatsbyPluginLoadableComponents(),
    ...core.getGatsbyPluginTypeScriptConfig(),
    ...core.getGastbyCorePluginConfig({
      packageName: packageJson.name,
      designSystemPagesPath: path.join(__dirname, '..', 'cdpq-design-system-docs', 'docs'),
      renderCoreDocsPages: false,
      renderDesignSystemPages: true,
      renderDocsPages: false,
    }),
    /** svg */
    core.getGatsbyReactSvgrSvgoConfig(),
    /** gatsby plugin image */
    ...core.getGatsbyImagePlugins(),
    /** css */
    core.getGastbyPluginTreatConfig(),
    core.getGastbyPluginVanilla(),
    core.getGatsbyPluginPostCSS(),
    /** mdx */
    core.getGatsbyPluginCatchLinks(),
    ...core.getGatsbyPluginMdx(),
    /** images and assets */
    ...core.getGatsbyImageFolder({
      pathImgDir: [
        path.join(__dirname, `../cdpq-design-system/src/assets/fonts`),
        path.join(__dirname, `../cdpq-design-system/src/assets/images`),
        path.join(__dirname, `../cdpq-design-system/src/assets/logos`),
        path.join(__dirname, `./src/images`),
      ],
    }),
    /** seo */
    core.getGatsbyPluginSitemap(),
    core.getGatsbyPluginRobotsTxt({ env, disallowAll: true }),
    /** cdn / deploy */
    /** optional font loading optimization */
    core.getGatsbyPluginPreloadFonts(),
  ],
};

export default config;

I was fighting with ts-node so it compiles the files in other packages like @newrade/core-gatsb-config but there is this line preventing it:

        const ignoreRules: IgnoreFn[] = [
            // Module must be a part of the current project
            (fname) => !fname.startsWith(projectRoot),
            // Module must not be a node_modules dependency of
            // the current project
            (fname) => fname.startsWith(
                path.join(projectRoot, "node_modules"),
            ),
        ];

simply commented out the line to ignore other files than project files... and everything work for my case

Is this something that we can add? I feel it's fairly common to consume other source files in .ts in a monorepo.

Thanks,

As mentioned here, Gatsby has an issue with a plugin modifying nodes that "it didn't create". It seems to only apply when gatsby-node is found in the project root; it works fine when it is located in a sub directory.

Perhaps, because of this, in order to use a plugin like this, storing the configuration files in a sub-directory should be mandatory. That could, potentially, raise compatibility concerns with various other 3rd party plugins, or any Gatsby process that requires the presence of these files in the project root. My testing thus far hasn't exposed compatibility concerns like that yet, but I would wager a guess that they exist.

I'm not sure yet if there's a decent, and stable, fix for this. Perhaps, in a scenario where a certain config file is required to be in the root, a "split" could be set up. The bulk of the work could be done in Typescript, in a sub-directory, and a root copy/stub could be created for compatibility with whatever process needs it. I really not a fan of having to maintain split configurations, though; that's definitely something I'm trying to avoid.

More investigation is required.

cc/ @d4rekanguok - thought you might be interested in my findings on this particular subject

First of all, I love the plugin, and thank you so much for building it! 😄

I am using Kentico as the CMS for my application. The @kentico/gatsby-source-kontent package defines the GraphQL types. I try to leverage the sourceNodes API to create special typing:

export const sourceNodes = ({actions: {createTypes}}: SourceNodesArgs) => {
  createTypes(`
    type kontent_item_rich_text_element_link {
      element: Node! @link(from: "element___NODE")
    }
  `)
}

But, when I run a gatsby develop, I get this:

warn Plugin `gatsby-plugin-ts-config` tried to define the GraphQL type `kontent_item_rich_text_element_link`, which has already been defined by the plugin `@kentico/gatsby-source-kontent`.

My theory is that @kentico/gatsby-source-kontent defines the type and then gatsby-plugin-ts-config tries to redefine the type, so Gatsby throws the warning and doesn't allow the plugin to do so. As a result, my custom typing does not work. This may not even be an issue with this plugin but any direction is helpful! Perhaps there is a way to tell Gatsby to allow this?

I appreciate your time and intention with this plugin! Let me know if there is anything else I can provide to help explain the issue better. 😄

Hey @ Js-Brecht, thank you for the nice work and I think this should have happened earlier.

I looked at this in the morning and thought a few things.

1. Isolating the .gatsby folder look pretty, but 3rd party plugins that hardcode the gatsby- * file path can cause problems. Ironically, even this plugin one of them itself.

2. Using a custom compiler with gatsby code can break compatibility with Gatsby's query compiler. Only transpilers can be used, and babel-preset-gatsby and babel-preset-gatsby-package are the only "official" support for it.

3. I prefer to use babel-node over ts-node because of 2 and the extendabilities (ex, I use babel/plugin-transform-named-capturing-groups-regex for my plugin). If you don't consider extensions, alternatives like sucrase might be a better option. because it shouldn't be "compile" and just faster is better.

4. Is it support yarn 2? Gatsby puts a lot of effort into compatibility with yarn 2, and this kind of meta plugin should do as well.

I add custom babel in Gatsby project but it seems like to resolve completed.

project: https://github.com/kamontat/kamontat/pull/81
ci build error: https://app.circleci.com/pipelines/github/kamontat/kamontat/175/workflows/ef23c3ce-8bfe-41e7-a36d-037daa12d9cb/jobs/439

With > 2.0 I ran into Cannot use import statement outside a module errors, when transpiling with ts-node instead of babel. I do this because I want to have my Gatsby config files type checked.

gatsby-config.js:

const { useGatsbyConfig } = require('gatsby-plugin-ts-config');

module.exports = useGatsbyConfig("./.gatsby/gatsby-config", {
  type: 'ts-node'
});

.gatsby/gatsby-config.ts:

import { TSConfigFn } from "gatsby-plugin-ts-config";

const configuration: TSConfigFn<'config'> = ({ projectRoot }) => ({
  siteMetadata: {
    title: `Gatsby Default Starter`,
    description: `Kick off your next, great Gatsby project with this default starter. This barebones starter ships with the main Gatsby configuration files you might need.`,
    author: `@gatsbyjs`,
    siteUrl: `https://gatsbystarterdefaultsource.gatsbyjs.io/`,
  },
  plugins: [
    `gatsby-plugin-react-helmet`,
    `gatsby-plugin-image`,
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `images`,
        path: `${projectRoot}/src/images`,
      },
    },
    {
      resolve: `gatsby-plugin-emotion`,
      options: {
        // Accepts the following options, all of which are defined by `@emotion/babel-plugin` plugin.
        // The values for each key in this example are the defaults the plugin uses.
        sourceMap: true,
        autoLabel: "dev-only",
        labelFormat: `[local]`,
        cssPropOptimization: true,
      },
    },
    `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: `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 configuration;

tsconfig.json:

{
  // This is an alias to @tsconfig/node12: https://github.com/tsconfig/bases
  "extends": "ts-node/node16/tsconfig.json",
  "include": [
    "./src/**/*",
    "./.gatsby/**/*",
    "./graphql-types.ts",
    "gatsby-browser.ts",
    "gatsby-ssr.ts"
  ],
  // Most ts-node options can be specified here using their programmatic names.
  "ts-node": {
    // It is faster to skip typechecking.
    // Remove if you want ts-node to do typechecking.
    "transpileOnly": false,
    "files": true,
    "compilerOptions": {
      "module": "CommonJS"
    }
  },
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "lib": [
      "dom",
      "ES2017",
      "ES2019"
    ],
    // "allowJs": true,
    // "checkJs": true,
    "jsx": "react",
    "strict": true,
    "esModuleInterop": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "noEmit": true,
    "skipLibCheck": true,
    "moduleResolution": "node",
    "resolveJsonModule": true
  }
}

The error looks like this:

  Error: /workspaces/gatsby-starter-dogmatism/.gatsby/gatsby-config.ts:1
  (function (exports, require, module, __filename, __dirname) { import { TSConfigFn } from "gatsby-plugin-ts-config";
                                                                ^^^^^^
  SyntaxError: Cannot use import statement outside a module

I've been doing this with v1 successfully. Any ideas what I'm doing wrong?

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.

💪

I ran into an issue that's quite similar to #12, but instead of being for locally developed plugins, it's for plugins residing in the "local" node_modules directory.
My project uses yarn workspaces, which has decided not to hoist one of the plugins used for my gatsby project.

Error message:

Couldn't find the "gatsby-plugin-graphql-codegen" plugin declared in "/Users/mikael/git/portal-web/node_modules/gatsby-plugin-ts-config/gatsby-config.js".

Tried looking for an installed package in the following paths:

• /Users/mikael/git/portal-web/node_modules/gatsby/dist/bootstrap/load-themes/node_modules/gatsby-plugin-graphql-codegen
• /Users/mikael/git/portal-web/node_modules/gatsby/dist/bootstrap/node_modules/gatsby-plugin-graphql-codegen
• /Users/mikael/git/portal-web/node_modules/gatsby/dist/node_modules/gatsby-plugin-graphql-codegen
• /Users/mikael/git/portal-web/node_modules/gatsby/node_modules/gatsby-plugin-graphql-codegen
• /Users/mikael/git/portal-web/node_modules/gatsby-plugin-graphql-codegen
• /Users/mikael/git/sit/node_modules/gatsby-plugin-graphql-codegen
• /Users/mikael/git/node_modules/gatsby-plugin-graphql-codegen
• /Users/mikael/node_modules/gatsby-plugin-graphql-codegen
• /Users/node_modules/gatsby-plugin-graphql-codegen
• /node_modules/gatsby-plugin-graphql-codegen

not finished open and validate gatsby-configs - 2.904s

Folder structure:

Originally posted by @JosXa in #2 (comment)

storing the configuration files in a sub-directory should be mandatory

The documentation at https://github.com/Js-Brecht/gatsby-plugin-ts-config#extended-usage suggests to use a "dot folder" named .gatsby:

// gatsby-config.js
const { generateConfig } = require('gatsby-plugin-ts-config');
module.exports = generateConfig({
    projectRoot: __dirname, // <- not required.  If omitted, projectRoot will be process.cwd()
    configDir: '.gatsby'
});

I ran into troubles with this in combination with gatsby-plugin-typegen, as it outputs a global, non-importable module declaration where the references cannot be found because by default TypeScript does not include any sources from folders starting with a dot. I suggest changing this or clarifying in the readme that having a dotted folder is going to require extra work in tsconfig.json.
I eventually settled on just naming the folder gatsby-config(s), which is maybe a little redundant containing a file with the same name and .ts, but gets the job done.

Hello!

I get a few warnings about Webpack Cache when using the following project structure:

.
├── gatsby
│   └── config.ts
├── gatsby-browser.ts
├── gatsby-config.js
├── gatsby-nonde.ts
├── gatsby-ssr.ts

I've configured only gatsby-config.js to point to gatsby/config.ts.

The warning looks like this:

Error: <w> [webpack.cache.PackFileCacheStrategy] Caching failed for pack: Error: Can't resolve 'path/to/project/root/gatsby-node.js'

I think the caching mechanism is looking for a specific gatsby-node.js file and cannot resolve for .ts.

I found this comment (gatsbyjs/gatsby#28331 (comment)), that seems to address the problem.

My workaround is to configure gatsby-node.js to point to a slightly refactored gatsby/node.ts.
I hope this helps anyone who might be facing an issue with caching.

Thank you for actively maintaining this project!

Hello, I have just started using this plugin. Great stuff, allowed me to reuse some of my TypeScript config.

I am currently having one big issue while rewriting the app to new version. createPages scripts runs indefinitely while using the plugin. Works normally with createPages script in gatsby-node.js.

I will create repo to reproduce the error and update this issue when I do.

EDIT: https://github.com/Pernick/gatsby-ts-config-create-pages-stuck

While I am doing that - I just wanted to ask if anyone encountered this issue with this plugin specifically. I have noticed that this issue occurred for many people due to different reasons, but in this case I can confirm it being caused by gatsby-plugin-ts-config.

Some additional info:

• issue prevails with named and default exports
• issue prevails for both babel and ts-node types

Hey there,

I'm using this in a project that uses the latest gatsby version. Everything seems fine. However, npm complains that the peer dependency constraint is violated as this plugin specifies ~2.x.x || ~3.x.x. Is this intentional or could we bump this to also include ~4.x.x?

I've got a build issue that could be my setup, but it used to work in the old version so I'm not sure what I've missed...

Basically on build I get

TypeError: [gatsby-plugin-ts-config]: Cannot read property 'default' of undefined

inside transpiler.ts on line 121. If I add an additional null check to exports everything works ok, e.g

if (exports && exports.default) delete exports.default;

Didn't want to do a PR without checking that it wasn't just my setup causing the issue which is

./gatsby-config.js

const { useGatsbyConfig  } = require('gatsby-plugin-ts-config');

module.exports = useGatsbyConfig(".gatsby/gatsby-config", {
  type: 'ts-node'
});

.gatsby/gatsby-config.ts

import { GatsbyConfig } from 'gatsby';

const config: GatsbyConfig = {
  siteMetadata: { ...blah etc. }
}

export default config;

(Amazing work on 2.0 by the way, was very excited to see a major update like this!)

I have a workspace like so:

//workspace package.json
{
  "workspaces": [
    "gatsby-theme-project-core",
    "gatsby-theme-project-uses-core",
    "my-site"
  ],
  "resolutions": {
    "gatsby-theme-project-core": "*",
    "gatsby-theme-project-using-core": "*"
  }
}

both project-core and project-uses-core have a gatsby-config.js of

const tsconfig = require("gatsby-plugin-ts-config")

module.exports = tsconfig.generateConfig({
  configDir: ".gatsby",
  projectRoot: __dirname,
})

my-site does not use gatsby-plugin-ts-config, and uses a more normal gatsby-config.js of just requiring the two above. It's purpose is to only hold content.

And when I go to run yarn workspace my-site run build locally after a clean, I get an "open and validate gatsby-configs" that lasts forever.

When using gatsby-plugin-image with gatsby-plugin-ts-config, we get the following error on gatsby develop:

There was a problem loading plugin "gatsby-plugin-image". Perhaps you need to install its package?

Running gatsby develop --verbose errors out with a bit more information:

plugin "gatsby-plugin-image" threw the following error:
 ENOENT: no such file or directory, open 'node_modules/gatsby-plugin-image/dist/package.json'

Indeed, that file does not exist on the filesystem even though the gatsby-plugin-image module is present within package.json and the module is installed. However, converting gatsby-config.ts back to gatsby-config.js allows build to complete successfully without any further changes.

Hey!
Excited to get my config files in Typescript, but I ran in to a hiccup importing a constant from a .tsx file.

 Error: [gatsby-plugin-ts-config] An error occurred while reading your gatsby-node!
  [BABEL] <my-path>.../src/utils/constants.tsx: @babel/preset-typescript: isTSX:true requires allExtensions:true (While
 processing:   "<my-path>.../node_modules/@babel/preset-typescript/lib/index.js")

I can't find a way to enable

options: {
  isTSX: true,
  allExtensions: true,
},

somewhere....
I tried setting it in both my gatsby-config.js and a .babelrc

gatsby-config.js
babel: {
      presets: [
        [
          require.resolve("@babel/preset-typescript"),
          {
            name: "@babel/preset-typescript",
            options: {
              isTSX: true,
              allExtensions: true,
            },
          },
          "override",
        ],
      ],

// .babelrc
{
  "presets": [
    [
      "@babel/preset-typescript",
      {
        "isTSX": true,
        "allExtensions": true
      },
      "test"
    ]
  ]
}

I added a plugin gatsby-plugin-root-import into plugins in gatsby-config.js file like the following.

    {
      resolve: "gatsby-plugin-root-import",
      options: {
        src: path.join(__dirname, "src"),
      },
    },

yet it doesn't seem to be working when I import files using the absolute path in gatsby-node.ts

Hi,
thanks for your work on this plugin.

I've an issue while trying to deploy my site.

11:42:11 AM: $ gatsby build
11:42:14 AM: error [gatsby-plugin-ts-config] An error occurred while reading your gatsby-config!
11:42:14 AM: [BABEL] /opt/build/repo/config/gatsby-config.ts: `babel-preset-gatsby` has been loaded, which consumes config generated by the Gatsby CLI. Set `NODE_ENV=test` to bypass, or run `gatsby build` first. (While processing: "/opt/build/repo/node_modules/babel-preset-gatsby/index.js")

You can see the full log here:
https://app.netlify.com/sites/resap/deploys/60a38bb6dc0cb40008db1dd8

The linked repo is this one: https://github.com/mathieutu/resap/

Do you have any idea of where it could come from?

Thanks.

Yesterday, Gatsby v3 got released. I've upgraded already two projects. They also use gatsby-plugin-ts-config. So far everything seems to work! Awesome 🥇

After some more testing I think the peer dependency should be updated and a new version released.

warn Plugin gatsby-plugin-ts-config is not compatible with your gatsby version 3.0.0 - It requires gatsby@~2.x.x

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.