Option for adding variables with PropTypes.

[ruslanxdev]

Hi!
We need this case for add our d.ts interfaces to JS as PropTypes. This is a temporary solution when moving our internal library from JS to TS. In the circumstances of using our library in both JS and TS projects.

• addVariables (boolean) - Adding variables for props. Defaults to false.

module.exports = {
  plugins: [['babel-plugin-typescript-to-proptypes', { addVariables: true }]],
};

// Example.d.ts
// Before
import React from 'react';

export interface Props {
  name?: string;
}

// After
import React from 'react';
import PropTypes from 'prop-types';

export const Props = {
  name: PropTypes.string
};

// Example.js
import React from 'react';
import Props from './Example.d.ts';

export class Example extends React.Component {
  static propTypes = Props;

  render() {
    return <div />;
  }
}

[ruslanxdev]

I will try resolve conflicts.

[milesj]

I'm curious why you're using/importing .d.ts for this?

[ruslanxdev]

This is a temporary solution.
Now our library is written on JS. But it is using in TS projects. Therefore, we need d.ts for our users, and we need PropTypes for us. But we don't want to duplicate it.
When we full rewrite our library on TypeScript we don't need PropTypes. We will use only TS types.

[milesj]

@ruslankhh Just trying to understand your process. So are you generating TS declarations and then compiling the .d.ts files with Babel?

[ruslanxdev]

Nope)

1. We write TS declarations in .d.ts.
2. We write component in JS.
3. We require .d.ts in JS.
4. We compiling .d.ts to PropTypes with Babel
   4.1. ...in runtime (with webpack and babel-loader).
   4.2. ...in build with replace require('*.d.ts') to code (with babel-plugin-transform-ts-import).
5. We set the PropTypes to component in JS.

[milesj]

Unrelated to this PR, I'd highly suggest not using .d.ts in your actual application, as it means something very specific in the TS world.

[milesj]

Instead of addVariables, let's call it exportVariableDeclarations.

[ruslanxdev]

Yes, but maybe call declarePropTypeVariables? It's not only export:
https://github.com/milesj/babel-plugin-typescript-to-proptypes/pull/1/files#diff-ada6231da2b06b9c22c8023a81419998R15

[milesj]

I think instead of assuming that typeName === a variable, you should check for imports and validate that it's actually a variable.

[ruslanxdev]

What do you mean?

[ruslanxdev]

For this?

export default class ClassStandard extends React.Component<{ name: string }> {
  render() {
    return null;
  }
}

Like that?

const isVariable = (
  state.options.declarePropTypeVariables &&
  typeNames.length === 1 &&
  state.componentTypes[typeNames[0]]
);

[ruslanxdev]

Or do you mean to check if such a variable exists?
But it's redundant. We create it in the same location where we save this type in state:

babel-plugin-typescript-to-proptypes/src/index.ts

Lines 210 to 218 in afb36e2

	state.componentTypes[node.id.name] = extractTypeProperties(
	node,
	state.componentTypes,
	);
	if (state.options.declarePropTypeVariables) {
	addVariable(path, node.id.name, state);
	}
	},

[ruslanxdev]

Or do you think I'm adding a variable just for export?
That's not so. A variable is created for all types:

babel-plugin-typescript-to-proptypes/tests/__snapshots__/index.test.ts.snap

Lines 186 to 199 in afb36e2

	interface Props {
	name: string;
	}
	const Props = {
	name: _pt.string.isRequired
	};
	export default class ClassCustomReactImportNamePure extends R.PureComponent<Props> {
	static propTypes = Props;
	render() {
	return null;
	}
	}"

[milesj]

We should only add variables when the interface is for props/state. We shouldn't do it for every interface.

[ruslanxdev]

How we can do it? Match with the name suffix Props|State?

[milesj]

You'll need to use the extracted generic names from classes/functions, and cross reference that.

[ruslanxdev]

What if we don't have classes/functions in d.ts?)

[ruslanxdev]

Or we should write everytime classes/function in d.ts?

[milesj]

I won't allow this feature if it generates for every interface/type alias that exists. That would blow up the filesize unnecessarily.

Maybe if the setting was a regex pattern:

declarePropTypesVariables: /(Props|State)$/,

[ruslanxdev]

I will think about it.

[ruslanxdev]

Our conversation got me thinking.
Maybe you're right and this is too specific for your plugin. I decided to make it all into another plugin that only works for definitions.
https://github.com/ruslankhh/babel-plugin-ts-definitions-to-proptypes
If you are interested in this PR, I can fix it as you suggest and you will merge it.

[milesj]

I think a fork might be best, as it's a very specific use case. Glad you got it working.