DocGen Typescript output appears to be dependent on source location?

[StevenLangbroek]

Bug Report

Describe the bug

I've configured my docz (0.13, but tried 1.0.0-rc8 as well) project for Typescript. When running in development mode I started getting warnings about re-exported types not existing, despite everything working seemingly fine. I'm fine ignoring these warnings, but CI breaks because it treats warnings as failures, and I can't find any documentation for disabling this behavior (leaving warnings as is)...

The warnings:

./src/typography.ts
Attempted import error: 'HeadingProps' is not exported from './typography/Heading.component'.
 @ ./docs/documents/tokens/space.mdx
 @ ./.docz/app/imports.js
 @ ./node_modules/docz/dist/index.m.js
 @ ./node_modules/docz-theme-default/dist/index.m.js
 @ ./.docz/app/root.jsx
 @ ./.docz/app/index.jsx
 @ multi ./node_modules/react-dev-utils/webpackHotDevClient.js ./node_modules/@babel/polyfill/lib/index.js ./.docz/app/index.jsx~~

To Reproduce

I honestly have no clue why this started happening now, but suspect it's a downstream in-range semver update... If you have any clues or a likely suspect I'd love to continue researching... I have a lockfile that works, and one that doesn't but the diff is so big I get lost.

Update

The original issue is easy enough to work around for now (by exporting interfaces where they're declared instead of at the end of the module), but the problem I'm describing in the last comments is more pernicious: whether or not a PropsTable renders seems to be affected by the path of the component relative to the document. You can see it if you run my repro in latest branch; the Props component doesn't display until you create a folder called src and move it in there.

The reason that this is such a problem is that we strictly separate documentation and source code by respective top-level folders docs and src, so to make PropsTable work, I have to do this:

// ./docs/components/GridPropsDummy.tsx
import { GridItemProps } from '../../src/grid';

export const GridItemPropsDummy: React.FunctionComponent<GridItemProps> = props => <div {...props} />

// ./docs/documents/grid.mdx
import { Props } from 'docz';
import { GridItemPropsDummy } from '../components/GridPropsDummy';

<Props of={GridItemPropsDummy} />

This works, but is frankly not great to have to explain when onboarding new devs ("Oh yeah just import it into the document and pass it to Props" vs "Well, you have to export your props interface, import them from a file that has to be in the docs folder, then create an empty dummy component, then import that into the document and pass it to Props")

This problem persists across versions too (0.13 -> 1.2)

[StevenLangbroek]

master-yarn.lock works, feature-yarn.lock doesn't:

https://gist.github.com/StevenLangbroek/4523a781f1ff085c06c97e4df21dd1ad

[fi3ework]

How is the Heading.component file look like. 🤔

[StevenLangbroek]

@fi3ework mostly:

import * as React from 'react';

interface HeadingProps {};

const Heading: React.FunctionComponent<HeadingProps> = props => {};

export default Heading;
export { HeadingProps };

I've also tried exporting where they're declared, but that made no discernible difference...

[StevenLangbroek]

(to be clear, there's about 5-6 of these warnings)

[StevenLangbroek]

I have some time now, so working on repro, apologies for not providing one before.

[StevenLangbroek]

Here you go:

https://github.com/StevenLangbroek/docz-ts-repro

Clone and run yarn && yarn docz dev:

[StevenLangbroek]

Is there anything I can do to help fix this?

[StevenLangbroek]

Ping @pedronauck

[rohmanhm]

Is this fix your issue? #771

[StevenLangbroek]

It does not... Minimal repro linked to above is newer than that.

[StevenLangbroek]

I updated everything to latest and still can't get a table for a Typescript component: https://github.com/StevenLangbroek/docz-ts-repro/tree/latest

[StevenLangbroek]

@rohmanhm @pedronauck the lack of properly working propstables for typescript makes this a hard sell internally. I want to help but I'm not even sure how to start debugging this...

[StevenLangbroek]

So, I've dug a bit further. If I move the component from the repro into src/Component.tsx, it works. Move it back into project root, broken again...

[StevenLangbroek]

@pedronauck any chance you can help me figure out how to solve this? I'll update my repro to latest to see if the problem still exists.

[tripphamm]

I'm having issues with Attempted import error as well.

e.g.

// src/Button/Button.tsx

export interface ButtonProps {
  whatever: string;
}

export const Button = (props) => <button {...props} />;

// src/Button/index.ts

export { Button, ButtonProps } from './Button';

// src/Button/Button.mdx

import { Button } from '.';

# Button

<Button>Sample</Button>

I'd get error:

Attempted import error: 'ButtonProps' is not exported from './Button'.

With my project's structure, I'm not able to use the same workaround as @StevenLangbroek (simply export types where they're defined and don't re-export), so I'm looking for another solution.

These warnings are flooding my console and drowning out real issues, so I'd really like to get rid of them. This might be related: https://github.com/TypeStrong/ts-loader#transpileonly-boolean-defaultfalse although it doesn't look like docz uses ts-loader...

At this point, I'm fine with simply suppressing the warnings (rather than fixing the underlying issue which may be beyond the scope of the docz project).

Webpack allows for suppressing warnings via the stats config option (https://webpack.js.org/configuration/stats/), so I tried hooking in to the docz webpack config in order to set the appropriate configs, but neither modifyBundlerConfig nor onCreateWebpackChain are working for me.

This is what I've tried:

// .doczrc.js

module.exports = {
  ...
  modifyBundlerConfig: (config) => {
    config.stats = { warnings: false };
    config.devServer = { stats: { warnings: false } };

    return config;
  },
  onCreateWebpackChain: (config) => {
    config.stats({ warnings: false });
    config.devServer.stats({ warnings: false });

    return config;
  }
}

I'm wondering if my overrides of stats are getting blown away at some point, or if I'm using them incorrectly. console.logging the config before the return in each hook reveals that the config is being set the way that I expect; I'm just still seeing the warnings no matter what I do.

[sebald]

We have a monorepo and running in the same problem. docz lives in a separate package (packages/website) and while importing a component from packages/component via path alias works, the propss table doesn't.

[StevenLangbroek]

So I did some digging through DevTools, @pedronauck am I correct in saying that the __filemeta__ prop needs to match one of the entries in the DoczStateProvider, but mismatches for some reason? If so, how do I control this further? And follow-up question; is this still a relevant thing now that next relies on Gatsby?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rakannimer]

Hey all,

I'm sorry for the delay in answering this .

I know you're using v1 but I will answer for v2 as that's where I can be most helpful. If you would like to upgrade to v2 but are facing issues please open an issue so we can help and make the migration process easier for others.

Hey @StevenLangbroek

So I did some digging through DevTools, @pedronauck am I correct in saying that > the filemeta prop needs to match one of the entries in the DoczStateProvider, but mismatches for some reason?

I'm not sure what the problem that's happening is exactly, but it looks like either that or the component file is not being compiled at all by react-docgen(-typescript) because the default filterComponents method only lets through files that start with a capital letter ( we might want to change that though or document that behavior ).

EDIT: this is no longer the case starting from 2.0.0-rc.67

The solution is usually to allow the component to be parsed by providing a custom filterComponents method to your doczrc.js and/or pointing docgen to the right place to look for components using docgenConfig.searchPath

I submitted a PR to your repro that fixed the issue for me by updating to docz v2 and customizing filterComponents : StevenLangbroek/docz-ts-repro#1

Is upgrading to docz v2 a possibility for you ?

Hey @sebald

We added an example recently to showcase one way to do what you're looking for here : https://github.com/doczjs/docz/tree/master/examples/monorepo-separate-docs/

Does that help ?

In particular make sure to read the notes : https://github.com/doczjs/docz/tree/master/examples/monorepo-separate-docs#notes

Hey @tripphamm

Did you try upgrading to v2 ?

[design1online]

I got this error when the file that was throwing an error had an improperly formatted propTypes block. It had a syntax error in it that was then somehow throwing these missing import error instead. Check to see if the file it's saying is missing an import has a syntax error somewhere in the propTypes or defaultPropTypes.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.