feat: generate type declarations

[danice]

Proposed changes

Generate typescript .d.ts type files. This allows vs code intellisense.

Screenshots (if appropriate) or codepen:

Types of changes

• Bug fix (non-breaking change which fixes an issue).
• New feature (non-breaking change which adds functionality).
• Breaking change (fix or feature that would cause existing functionality to change).

Checklist:

• I have read the CONTRIBUTING document.
• My commit messages follows the conventional commit format
• My change requires a change to the documentation, and updated it accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[wuda-io]

is this really a good idea? I have to check locally first...

[danice]

I'm also doing more tests about this. Not about adding dist folder to gitignore, but about the way types are exported to be used from other modules.

I think the standard way will be not the one used here, but adding a index.ts class that re-export all types like

export * from './global';
export { Toast } from './toasts';
export { Tabs } from './tabs';
export { Sidenav } from './sidenav';
export { Collapsible } from './collapsible';
export { Dropdown } from './dropdown';

and set this as the "typings": "dist/src/index.d.ts" entrypoint for the package.

This will allow to use import each class as

import { Sidenav  } from '@materializecss/materialize';

But of course all this need to be tested in the different kinds of project to check it works correctly for all.
For the moment I think is better do not include this.

[danice]

As said in the previous comment I have changed the way types are exported.
Now it follows the standard way of re-exporting all types from a index.ts file.

In practical terms this means that to import some class instead of having to define each class path in the library as

import { Tabs } from '@materializecss/materialize/dist/src/tabs';

now all classes can be imported from @materializecss/materialize as

import { Collapsible, Tabs } from '@materializecss/materialize';

For projects that are using typescript and importing types this is a big difference: without this change, using materialize from a typescript project is NOT complete.

As a side note I need also those changes to use materialize as a monorepo. I think "monorepo" is a very interesting option to work MUCH faster of materialize, as you don't need to deploy nothing, you change the compo and you see the change immediately.
I think that's and important topic, and I would open a discussion about that, but only if there is some interest.... and looking at the feedback received on my previous discussions i don't think this will happen.

[wuda-io]

Sure, that sounds nice! We can discuss everything here. The only thing why i did not merge your change was because you added the dist folder into the gitignore. This will cause errors during the release process.
I dont know why this was done and asked about it. Thanks for your ideas and improvements. They are really helpful and important for the project. I am looking forward for the next improvements. Please describe in more detail how you use your solution step by step so that I can test it better, then it is easier for me to understand why it is so useful. Thank you and good work 👍

[danice]

Ok, I see, sorry for the confusion...
Adding dist was because I changed the output dir in tsconfig to this folder
"outDir": "./dist",
And then it generates lots of "dist\src\autocomplete.d.ts" like files.

Adding dist to gitignore seems normal, following the common practice of not including build generated files in the source control.

One solution could be just adding "dist/src" to .gitignore. But maybe we will face the same problem in the package distribution files.

Maybe this is the solution for this issue. I would prepare an update:

• just adding "dist/src" to gitignore
• adding a .npmignore file exactly like gitignore but including all dist

What do you think?

[danice]

As commented I have changed gitignore to "dist/src" and added a .npmignore file exactly like gitignore but including all dist.
I think with this configuration it should generate a package with type info...

[wuda-io]

What is the first commit? It contains Styles and I like it, but why is it in this PR?
Sorry, but I am a bit confused. I can not merge because i dont fully understand.

[wuda-io]

Can you make the style changes and the Type-Changes in seperate PRs?
Then we can progress faster an I can more easily merge the PRs. Thank you.

[danice]

Can you make the style changes and the Type-Changes in seperate PRs? Then we can progress faster an I can more easily merge the PRs. Thank you.

Sorry, this was unintended... I have updated the PR including only the type declarations commit.

[wuda-io]

Haha ok thats fine.
But I also like the Style changes. It looked like, that you have implemented a primary and secondary color system which would be very awesome. It would be nice if you could provide this as a seperate PR too.

Also I talked recently with the old team members and one of them told me it would be a good idea to start as a new repo to avoid distraction from the old materializecss. That would also give the possibility to clean many things up or remove (maybe grunt). Also i would suggest to give you @danice and @mauromascarenhas more rights, in order to check in PRs faster. What do you or others think about this?

Oh sorry not old team member. I ment inactive from this team here.

[danice]

Created PR for M3 styles.

About the new repo question, please have a look to the "Modern development environment using a vite monorepo with materialize as a package" discussion.

I would suggest removing from the materialize repo all the website stuff, and creating a separated repo for the website that would include materialize repo as a "monorepo" package and also as git submodule (see the linked project as an example of how it will look).

This "monorepo" is a very practical development environment, but of course it requires to be familiar with git submodules. My experience is that for this is better to use (at least a as complement) some git client like git extensions as - at least for me- Visual Studio is not very friendly with submodules.

[wuda-io]

Yes, that sounds good! The only concerns i have:

Does handlebars also work serverside to pre-compile all the pages?
That is better for SEO and also compile in multi languages and even keep old versions.

I will make a new Repo in the next days and then we can continue splitting the project step by step.

[danice]

Does handlebars also work serverside to pre-compile all the pages?

Yes, the pnpm build generates a dist folder of "plain" version of html pages with all the partials resolved.

[wuda-io]

LGTM, is it ready for merging?

[danice]

I have done some fixes for ts type errors and to maintain M import as default ("import M from ...", without { M } ) to keep backward compatibility.
I have re-checked in webpack and "js import" project and it works fine.
So I think it's ready for merge...

[wuda-io]

That are some serious pro-moves dude! Haha awesome, I'll merge it.